
BASIC is a simple yet very powerful 
language found on nearly all home 
micros, but there are times when it is just 
not practical to use. One such example 
is when we try to write fast action 
games. 

Don’t get me wrong, Basic is still very 
good for writing games - as you can see 
from the quality of those in The Micro 
User . But Pm sure there have been 
several occasions when you’ve wanted 
to move objects smoothly around the 
screen without the dreaded flicker. 

Over the next few months I’ll be 
covering all you need to know about 
writing machine code games -everthing 
from sprites to OSBYTEs. 

The articles will be written assuming 
you know the basics of 6502 machine 
code. 

Most games are written in Mode 2 
because it offers a medium resolution 
screen with 16 colours. For this reason 
nearly all the articles will be devoted to 
writing games in Mode 2. 

However, most of the programs can 
be adapted to work in other modes as 
they usually require only a few 
modifications. 

Like all things, we have to start at the 
bottom and work our way up. This is 
why the first couple of articles will be 
concentrating on the configuration of 
the Mode 2 screen. We need to know 
how the screen is arranged before we 
can display objects on it. 

I could throw you in the deep end by 
introducing a full machine code sprite 
routine, or a program to scroll 
landscape across the screen, but Til 
leave them until we are in a position not 
only to do so, but also to understand 
how we’re doing it! 

As you may already know, the Mode 
2 screen uses up 20k of memory to store 
the display. This 20k is known as the 
video RAM. 

The start of video RAM can be found 
by printing the value of HIMEM - in 
Modes 0, 1 and 2 HIMEM is 12288 
(&3000 in hex). The last byte of 
memory used by the video RAM in any 
mode is &7FFF - just below the 
sideways ROM area. 

The Mode 2 display consists of 32 
rows of 20 characters. The video RAM 
is divided up into strips which go across 
the screen from left to right, starting at 
the top left of the screen. 

These strips directly correspond to 


the 32 character rows. Each row or strip 
of the screen takes up 640 bytes. 

Since 20k is equal to 20*1024 bytes 
(20480), dividing it into 32 rows gives 
640 bytes (&280 in hex) per row. 

These strips are now split into 80 sets 
of eight vertical bytes (8*80=640) to 
give 80 columns. This is getting a bit 
complex so it’s time to simplify things - 
see Figure I. 

This shows the top of the Mode 2 
screen - assuming no scrolling has 
occurred. If it has the start address will 
be different, but the screen will still be 
organised in much the same way. 

The top left location is &3000 
(HIMEM) the next location down is 
&3001 and so on down the column to 
location &3007. At this point the next 
location down is &3280 — note that this 


is on the next character row. 

Surely , it would be more logical if this 
had been location &3008? Maybe, but 
the way the screen has been arranged on 
the BBC Micro is very useful, as we will 
see in future articles. 

If you look back to the first row, to 
the start of the column right of location 
&3000 you will see location &3008. 
Now go down from here and you will 
find &3009, &300A and so on down to 
location &300F. 

Again, after eight bytes we start a 
new column on the same row. This is 
repeated 80 times on each row. 

After 80 columns we start at the 
beginning of the next row down. The 
second row is arranged in the same way 
as the first - this time the row starts at 
location &3280, &3000+(80 columns * 




COLUMN 




0 

1 

2 - 

— 

78 

79 

HIMEM—► 

*<3000 

63008 

63010 

- 

63270 

63278 


*<3001 

63009 

63011 

- 

63271 

63279 


*(3002 

6300A 

63012 

- 

63272 

6327A 

ROM 0 

*(3003 

63008 

63013 

- 

63273 

6327B 


13004 

6300C 

63014 

- 

63274 

6327C 


*<3005 

6300D 

63015 

- 

63275 

6327D 


(3006 

6300E 

63016 

- 

63276 

6327E 


*(3007 

6300F 

63017 

- 

63277 

6327F 


*<32B0 

63288 

63290 

- 

634F0 

634F8 


*(3281 

63289 

63291 


634F1 

634F9 


63282 

6328A 

63292 

- 

634F2 

634FA 

ROM 1 

63283 

63288 

63293 

- 

634F3 

634FB 


63284 

6328C 

63294 

— 

634F4 

634FC 


632B5 

6328D 

63295 

- 

634F5 

634FD 


63286 

6328E 

63296 

- 

634F6 

634FE 


63287 

6328F 

63297 

' 

634F7 

634FF 


63S00 

63508 

63510 

- 

63770 

63778 


63501 

63509 

63511 

— 

63771 

63779 


63502 

6350A 

63512 

— 

63772 

6377A 

ROM 2 

63503 

6350B 

63513 

- 

63773 

6377B 


63504 

6350C 

63514 

— 

63774 

6377C 


63505 

63500 

63515 

— 

63775 

6377D 


63506 

6350E 

63516 

— 

63776 

6377E 


63507 

6350F 

63517 

— 

63777 

6377F 
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Part One 


8 bytes)-&3280. That’s why the next 
location down from &3007 is &3280. 

It’s now time for the first of many 
programs. 

Type in and run Program I. All it is 
designed to do is store the number 15 in 
each byte of the video RAM, starting 
from location &3000 (the top left 
corner) and ending at &7FFF - if you 
are prepared to wait that long. 

To slow it down a bit I arranged that 
a key must be pressed before the next 
location will be changed. 

You will notice that a wide yellow 
pixel appears on the screen each time 
you press a key - this may be difficult to 
see on a normal television set. In fact 
there are two pixels, side by side. 

These can be individually addressed 
with any of the 16 colours available - in 
this example they are the same colour 
because the number 15 means display 
two yellow pixels - we'll see why in a 
minute. If the number had been 
different, other colours would appear. 

The point is we now know that the 
colour of the two pixels can be changed 
by storing different numbers in the video 
RAM - the number must be in the range 
0 to 255 - a byte. 

Program II shows what happens 
when bytes 0 to 255 are stored 


10 REM PROGRAM I 
20 MODE 2 

30 VDU23|8202|0;0;0; 

40 bytc*15 

50 FOR location=*3000 TO 17FFF 
60 ?location*byte 
70 REPEAT UNTIL GET 
80 NEXT 


Program I 


10 REM PROGRAM II 
20 MODE 2 
30 byte-0 
40 REPEAT 
50 VDU31,0,6 
60 PRINT"Byte « ";byte 
70 FOR offsets TO IFF 
80 off®et?l3000 c byte 
90 offset?43288=byte 
100 offsit?W50i*byte 
110 NEXT 

120 REPEAT UNTIL 6ET 
130 byte»byte+l 
140 UNTIL byte>255 


Program II 


consecutively in the video RAM - only 
the first 256 bytes of rows 0,1 and 2 are 
changed, for speed. You should see 
three identical coloured sections of rows 
across the screen. 

Program III is identical to Program 
II, though this time machine code has 
been used to speed it up. 

Here’s a brief description of how 
Program III works: 


Line 

number 

100 Loads the accumulator with 
the byte that will be stored in 
the video RAM. 

110 Loads the X register with 0. 
This is used as an offset 
register. 

120 Stores the byte held in the 
accumulator at location 
&3000 + X, the start of row 
0 . 

130 Stores the byte at location 
&3280+X, row 1. 

140 Stores the byte at location 

&3500+X, row 2. 

150 Increments the offset register 

by one. 

160 Causes a branch if the X 
register is not 0. If X is zero, 
the loop is ended and the 
program returns to Basic 
because of the RTS in line 
170. 


10 

REM PROGRAM III 

20 

MODE 2 

30 

byte-0 

40 

REPEAT 

50 

VDU31,I,6 

60 

PRINT"Byte » "fbyte 

70 

FOR pass E 0 TO 2 STEP2 

80 

PX*4C00 

90 

COPT piss 

100 

.Start LDAIbyte 

110 

LDX40 

120 

.next STA13000,X 

130 

STA13280,X 

140 

STA&3S00,X 

150 

INX 

160 

8NE next 

170 

RTS 

180 

INEXT pass 

190 

CALL Start 

200 

REPEAT UNTIL 6ET 

210 

byte«byte+l 

228 

UNTIL byte>255 


Program III 


HDUITD 

WRITE 

MACHINE 

CHIDE 

GAMES 

By KEVIN 
EDWARDS 


Remember that the 6502 registers 
can only hold a number between 0 and 
255. So when the X register contains 
255 and an INX is executed, the X 
register will contain 0. This means that 
only the first 256 bytes on each line will 
be changed by the program - 0 to 255 
inclusive. 

To show how fast machine code is, 
type in and run Program IV and Run it. 
This puts the bytes 0 to 255 in all 20k of 
the video RAM. Press a key to 

- ► 


10 

REN PROGRAM IV 

20 

NODE 2 

30 

byte=0 

40 

REPEAT 

58 

FOR pasi>0 TO 2 STEP2 

60 

PMC00 

70 

[OPT pm 

80 

.Start LDAIbyte 

90 

LDXI0 

100 

.next STAW000,X 

118 

INX 

120 

BNE next 

130 

INC next+2 

140 

8PL next 

150 

RTS 

160 

INEXT pass 

170 

CALL Start 

180 

VDU31,5,15 

190 

PRINT'Byte ■ “ibyte 

200 

REPEAT UNTIL BET 

210 

byte*byte+l 

220 

UNTIL byt*>255 


Program IV 
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From Page 75 

increment the value of the byte stored in 
screen memory. 


Line 

number 


In Program IV loads the 
accumulator with the byte to 
be stored in the video RAM. 
Loads the X register with 0 - 
this is used as an offset. 
Stores the byte on the screen. 
Increments the offset register. 
Branches if the X register is 
not 0. The branch is not taken 
until the index register, X, has 
taken all of the values 0 to 
255. 

Increments the high byte of 
the screen address being 
changed. 

Branches to the next 256 
block if the address is still 
part of the video RAM. The 
screen ends at location 
&8000. The high byte of 
&8000 is negative, because 
bit 7 is set (&80 = 
% 10000000). That’s why we 
only branch if the result is 
positive. 


yellow and the right pixel red, we have to 
calculate the binary number for the 
colour of the left and right pixel - yellow 
is %0011 and red is %0001. Table I will 
help you convert colour numbers into 
binary. 

Now we interweave the bits of the two 
colours to make up the byte that will be 
stored in the video RAM. We get four 
bits from the colour of each pixel to 
make up eight bits (a byte). 

First of all we take the most 
significant bit (the left-most bit) from the 
left pixel’s colour - 0 in the case of 


yellow. This will be bit 7 of the byte we 
are creating. 

Now we take the most significant bit 
from the right pixel’s colour - 0 in the 
case of red. This is bit 6 of the new byte. 

We now repeat this procedure for the 
remaining 6 bits - 3 bits from each 
colour. Remember to take the first bit 
from the left colour and the next bit from 
the right colour. 

If this is done correctly you will finish 
up with the binary number %00001011 


The RTS in line 150 returns to Basic. 

What we must now do is find out the 
relationship between the byte stored in 
the video RAM and the colour of the 
two pixels displayed. 

To explain this easily we must use 
binary numbers. 

A nybble, for those who don’t know, 
is a four bit number - sometimes known 
as as half a byte. A byte consists of two 
nybbles - the top nybble and the bottom 
nybble. 

Each nybble has 16 different states 
(0-15, %0000 to %1111). This is very 
convenient for representing the 16 
colours in Mode 2. 

The logical way would be to use the 
top nybble (bits 4-7) of the byte being 
stored for the left pixel’s colour, and the 
lower bybble (bits 0-3) for the right 
pixel’s colour. 

But this isn’t the method used. 
Instead, we have to interweave the bits 
corresponding to the colours of the two 
pixels. 

This is quite fun, but a pain in the 
neck when the previously explained 
method could have been used. 

The reason for the interweaving is all 
to do with the hardware - it would be 
nice if they considered the people who 
have to write the software. 

If we want to make the left pixel 


Black 

Red 

Green 

Yellow 

Blue 

Magenta 

Cyan 

White 

Black/White 

Red/Cyan 

Breen/Magenta 

Yellow/Blue 

Blue/Yellow 

Magenta/Green 

Cyan/Red 

White/Black 


Table I: Colour number 
and binary equivalent 


guide for pixel colours 


left 

right 

colour 

e 

0 

Black 

2 

1 

Red 

a 

4 

6reen 

10 

5 

Yellow 

32 

16 

Blue 

34 

17 

Magenta 

40 

20 

Cyan 

42 

21 

White 

128 

64 

Black/White 

130 

65 

Red/Cyan 

136 

68 

Sreen/Magenta 

138 

69 

Yellom/Blue 

160 

80 

Blue/Yellow 

162 

81 

Hagenta/Breen 

168 

84 

Cyan/Red 

170 

85 

White/Black 

Table II: Ready-reference 
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(11 in decimal, &B in hex). 

Figure II should help clear the mist - 
take a look. 

If you change the variable byte to 11, 
in Program I, you’ll see that the left pixel 
will be yellow and the right pixel will be 
red. Hooray! It worked. 

To illustrate this further. I’ve written 
a program to calculate the byte to be 
stored given the colour of the left and 
right pixels. 

To ease the confusion, all numbers 
are displayed in binary. This helps to 
show how the bits have been 
interwoven. 

Type in Program V and try it. It's all 
in Basic so I’ll leave it up to you to find 
out how it works. 


X ABC0 -left pixel s colour. 

XEFGH -right pixel’s colour. 

A B C D 


6 H 

ill 


XAEBFCGDH s Byte. 


Program VI is the same as Program 
V but colour blocks now replace the 
binary numbers. 

Table II is a ready-reference guide to 
pixel colour combinations. For exam¬ 
ple, to calculate the byte required to 
produce a yellow pixel on the left and a 
blue pixel on the right you add up the 
numbers 10 and 16, resulting in 26. It’s 
as easy as that. 

So far we've concentrated on how the 
screen is mapped, and how each pixel 
can be set in any colour. This is vital 
knowledge whatever you’re doing. 

You see, graphics are all to do with 
making shapes on the screen by 
changing the contents of the video 
RAM - it’s just the same if you want to 
display a space invader or the letter Z. 

Most of this month’s programs are in 
Basic. This may seem a bit weird when 
the article is all about machine code 
games but it is easier to explain things 
initially in Basic. 

Don't worry, next month's article 
jumps deeper into the world of machine 
code, so swot up your 6502 as soon as 


Figure II: Interweaving pixels 

pUbblUIC. 

See you next month. 

10 REN PROGRAN V 

250 byte!*"" 

20 REM By Kevin Eduard* 

260 FOR bifl TO 4 

30 NODE 7 

270 bytel B bytel+CHRI(ASC (NIDI (left 

40 no*FALSE:ye*=TRUE 

nibble!,bit,1))) 

50 uant space=no 

280 bytel»bytel+CHRI(ASC(HlDI(right 

60 REPEAT 

.nibble!,bit,1))) 

70 INPUT"“Enter colour for left 

290 NEXT 

pixel (0-15)*,left 

300 PRINT)byte! 

80 UNTIL left>*0 AND left<16 

310 PRINTTABIII))"-. 

90 PRINT''left;■ ■ X") 

320 byte=0 

100 PROCbinary(left) 

330 FOR bit-8 TO 1 STEP -1 

110 left.nibbleMnibblel 

340 IF ASC(NIDI(byte!,bit,1)> =ASC"1 

120 REPEAT 

‘ THEN byte*byte+(2 A (8-bit)) 

130 INPUT" “Enter colour for right 

350 NEXT 

pixel (0-15)",right 

360 PRINT* *TAB(7);"Byte * ")bytej“ 

140 UNTIL right>»0 AND right<16 

or It* j '’byte 

150 PRINT''right;" = X"; 

370 END 

160 PROCbinary(right) 

380 DEFPROCbinary(nibble) 

170 right_nibblel»nibblel 

390 nibble!-"" 

180 PRINT*'TAB(10); 

400 FOR bit-3 TO 0 STEP -1 

190 uant_space B yes 

410 IF uant.ipace VDU ASC* * 

200 PROCbinary(left) 

420 IF nibble AND (2 A bit) VDU ASC*1 

210 PRINT'TAB(11 >j 

":bitl«*l" ELSE VDU ASC"0"«bitl*“0* 

220 PROCbinary(right) 

430 nibblel-nibblel+bitl 

230 PRINT * TAB(11)j. 

440 NEXT 

240 PR1NTTABI10)j"X"j 

450 ENDPROC 


Program V 


HDttlTD 

WRITE 

MACHINE 

□DDE 

GAMES 


10 REN PROGRAM VI 
20 REN By Kevin Eduard* 

30 0X»8 

40 VDU23,224,255,253,235,255,255,2 
55,255,235 

50 DIN pattern(1,15) 

60 FOR left.right*0 TO 1 
70 FOR colour=0 TO 15 
80 READ pattern(left right,colour) 
90 NEXT 
100 NEXT 
110 NODE 2 

120 FOR loop°0 TO 15 
130 COLOUR loop 
140 VDU 224,32 
150 COLOUR 7 
160 PRINT{loop,} 

170 NEXT 

180 INPUT''"Left ...".Left 
190 IF Left<0 OR Left>15 VDU7i80T0 
180 

200 INPUT*'"Right ...*,Right 
210 IF Right<0 OR RightMS VDU7:G0T 

0 200 

220 PRINT" 

230 COLOUR Left 
240 VDU 224 
250 COLOUR Right 
260 VDU 224 
270 COLOUR 7 
280 PRINT)* ■ ■) 

290 Byte=pattern(0,Left1^pattern(1, 
Right) 

300 PRINT;Byte;* or fj'Byte 
310 *FX15 

320 PRINT**"Preee SPACE to cont* 

330 REPEAT UNTIL 8ET»32 
340 60T0 110 

350 REN Data for left-hand pixel 
360 DATA0,2,8,10,32,34,40,42,128,13 
0,136,138,160,162,168,170 
370 REN Data for right-hand pixel 
380 DATA0,1,4,5,16,17,20,21,64,65,6 
8,69,80,81,84,85 

Program VI 
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Follow in the 
footsteps of 
Elite with the 
EOR method 


WE looked at the configuration of the 
Mode 2 screen last month and found out 
the colour of any pixel could be changed 
by storing different bytes in the relevant 
video RAM locations. 

Now we’ll go a bit further by joining 
several pixels together to form a 
character. 

We know that the Mode 2 screen 
consists of 32 strips or character rows. 
These are split into 80 vertical rows one 
byte in width, each being 8 pixels high 
and 2 pixels wide (2 pixels per byte in 
Mode 2). 

From this we can see that the number 
of characters per row in Mode 2 is 20. 
The 160 pixels horizontally (80 columns 
* 2 pixels), divided by 8 (width of a 
character in pixels) gives 20, therefore 
the number of bytes required to store a 
character is 32, not 64 as you might 
expect (8*8). 

This is because the character is 8 
bytes by 4 - remember that each 
horizontal byte corresponds to two 
pixels. 

Have a look at Diagram I. This 
shows the size of each character cell. 



Diagram I: Character cell dimensions 


You may think 24 bytes for one 
character is a bit wasteful when the 
VDU 23 command only requires eight 
byte parameters to define a shape of the 
same size. What you must remember is 
that a character defined by VDU 23 
cannot be multi-coloured. 

Let’s design a space invader, 8 pixels 
by 8. For this we will have to calculate 
the 24 bytes that represent the shape 
and colour we want the invader. 
Diagram II shows the bytes required to 
produce a red space invader. 

Table I in last month’s article will help 
you understand how the bytes were 
calculated. 

What we need to do now is find a way 
of displaying the space invader. 



Program I does this. The bytes of the 
video RAM are arranged in 8 byte 
columns. As we work our way down 
each column the memory location 
increases. So it would seem logical to 
store the data for the character in the 
same way. 

Storing the data like this allows us to 
use a simple indexing method to copy 
the bytes from outside the video RAM 
into the video RAM. The description of 
Program I gives the full details. 

Diagram III shows the data for a 
yellow face. Again, the face is 8 pixels 
by 8 - a character. For simplicity I’ve 


designed characters with only one 
foreground colour. 

You can use as many colours as you 
want for your own characters. The best 
way to design them is to use squared 
paper and felt tip pens. Then once 
you’ve finished designing your charac¬ 
ter you can calculate the bytes required 
to display the new shape. Substituting 
these with the data in Program I will 
allow you to see the results. 

A future article will include a 
multi-coloured character definer. This 
will help speed up the definition of 
characters. 

Program I can also be used to display 


10 REM PROGRAM I 
20 MODE 2 

30 FOR pass s 0 TO 2 STEP 2 
40 PX=S<B00 
50 COPT pass 
60 .start LDYI31 
70 .loopl LDAtCB0,Y 
80 .display STAfc5400,Y 
90 DEY 

100 BPL loopl 
110 RTS 
120 3NEXT 

130 FOR loop=0 TO 31 
140 READ data 
150 loop?l<C00=data 
160 NEXT 
170 CALL start 
180 END 

190 REM Space Invader data 
200 DATAl'1,3,1,1,0,1,2 
210 DATAB,3,1,3,2,3,0,B 
228 DATA0,3,2,3,1,3,0,B 
230 DATA2'2'3,2,2,0'2 f 1 


Program I: Plotting characters 
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the face. In fact, any data for an 8 by 8 
character will work with Program I. All 
you need to do is change the DATA 
lines to those shown in Listing I. It’s so 
simple - and so quick! 


190 REM Face data 
200 DATA5,15,10,15,15,19,15,5 
210 DATA15,15,5,15,15,5,0,15 
220 DATA15,15,10,15,15,10,0,15 
230 DATA10,15,5,15,15,15,15,10 

Listing I 

Program I’s space invader is stored in 
the video RAM starting at location 
&5400 and ending at location &541F- 
32 bytes. If we wanted to put another 
invader on the screen to the right of the 
existing one we would store the shape 
staring from location &5420 (&5400 + 
32=&5420). 

The 32 corresponds to the number of 
bytes needed to accommodate one 
character. We add this to the old start 
location to move the start address to the 
next character cell - the screen locations 
increase as you move to the right and 
decrease as you go to the left. Therefore 
to move one character cell to the left we 
would subtract 32 from the original 
start location. 

Program II is similar to Program I 
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Diagram III: Parameters 
for a yellow face 


except this time the start location is 
increased by 32 after each character is 
displayed and we also start at the top left 
of the screen. This moves the shape right 
by one character cell but leaves the 
previous shape on the screen. 

All we need to do now is delete the 
previous character to produce a moving 
object - for the majority of cases you 
will not want to leave a trail behind a 
moving character. 

The easiest way to delete a shape is to 
store zeros in the video RAM which 
contains the character data. 

Storing zero produces two black 
pixels on the screen. Since black is the 
normal background colour, the previous 
shape disappears - printing a space on 
the screen has exactly the same effect. 

The problem with deleting a shape in 
this way is that the background data is 
lost. A good example where problems 
would occur is in the arcade game 
Pacman. 

Here monsters move around a maze 


10 REM PROGRAM II 
20 MODE 2 

30 FOR pass=0 TO 2 STEP 2 
40 Py.=fcB00 
50 [OPT pass 
60 .start LDYI31 
70 .1oop1 LDAfcC00,Y 
80 .display STA&3800,Y 
90 DEY 

100 BPL loopl 
110 LDA display+1 
120 CLC 
130 ADCI32 
140 STA displays! 

150 BCC no^carry 
160 INC display+2 
170 ,no_carry RTS 
180 1NEXT 

190 FOR loop=0 TO 31 
200 READ data 
210 Ioop?l<C00=data 
220 NEXT 

230 FOR 1oop c l TO 200 
240 CALL start 
250 REPEAT UNTIL BET 
260 NEXT 
270 END 

280 REM Space Invader data 
290 DATA1,1,3,1,1,1,1,2 
300 DATA0,3,1,3,2,3,0,0 
310 DATA0,3,2,3,1,3,0,0 
320 DATA2,2,3,2,2,0,2,1 

Program II: 'Moving' shapes 


Part two 

HDUITD 

WRITE 

MACHINE 

CDDE 

GAMES 

By KEVIN 
EDWARDS 


which is filled with dots. Your aim is to 
guide another character around the 
maze so that he collects all the dots by 
moving over them. If the monster 
characters were deleted by storing zeros 
in the video RAM the dots would be 
destroyed as soon as one of the 
monsters passed over them. That’s 
rather pointless when the idea of the 
game is to eat up all the dots on the 
screen, for the monsters do it for you. 

The problem is solved by using the 
logical operator EOR (Exclusive OR). 
This is very useful because its effect on 
numbers is reversible. 

For example, consider two numbers 
X and Y. We shall define Z as being X 
EOR Y. The effect of EOR also allows 
us to say Y EOR Z=X and X EOR 
Z=Y. Using numbers, 1 EOR 2=3, 2 
EOR 3=1 and 1 EOR 3=2. 

The EOR function works by 
comparing corresponding bits of two 
bytes with each other, and depending on 
the state of the two bits produces a 
binary digit. This bit is used to build up a 
new byte - the resultant byte. 

Table I shows the resultant bit for the 


Bit n fra« 

Bit n froe 

Result 

1st byte 

2nd byte 

bit 

0 

0 

0 

0 

1 

1 

l 

0 

1 

l 

1 

0 


Table I: Truth table for EOR 
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From Page 75 

four possible conditions of the two bits 
being compared. In the table, n is the nth 
bit of the two bytes being compared. 

To show the EOR command in 
action we will EOR the numbers &9F 
and &54. 

The first thing we do is convert them 
into binary. Now we take the first bit 
from each byte and find the resultant bit 
- using the “truth table”. This bit is the 
first bit of the resultant byte. We now do 
exactly the same for the remaining seven 
bits to complete the new byte. 

If this seems rather complex you will 
be relieved to know that the 6502 has an 
EOR command that does all the work 
for you. Diagram IV shows how to 
calculate &9F EOR &54 by hand. 

To explain how EOR is used, 
consider &9F as being the background 
byte and &54 as the character byte. 
When the character passes over the 
background, and we use EOR to 
calculate the resultant byte which will be 
stored in the video RAM, we get &CB - 
&54 EOR &9F. 

When we want to move the character 
to a new position we EOR the screen 
byte (&CB) with the character byte 


19F = l 10011111 
&54 = l 01010100 


l 11001011 * fcCB or 195 


Diagram IV: EORing two bytes 


‘You will be 
relieved to 
know that the 
6502 has an 
EOR command 
that does all 
the work for 
you...' 


(&54) to move it off the screen. 

If all goes well we get the original 
background byte (&9F). This means 
that we’ve moved a character over a 
background without disturbing it. 
Problem solved? Well almost. 

So far we’ve dealt with EOR for one 
byte. So for a character which is several 
bytes in size we must perform the EOR 
on each byte we store in the video RAM. 

EOR has two drawbacks. When an 
object passes over another the resultant 
byte, and therefore colour, is not the 
same as the background byte or the 
character byte - this means that a 


colour change occurs. 

In the previous example we get &CB, 
which is totally different to the original 
bytes used. 

The other problem with EOR is that 
when the character byte and the 
background byte are the same the 


10 REM PROGRAM III 
20 MODE 2 

30 FOR pass=0 TO 2 STEP 2 
40 Py.=*B00 
50 tOPT pass 
60 .start LDYK31 
70 * 1oop1 LDAlcC00,Y 
80 EOR&5400,Y 
90 .display STA&5400,Y 
100 DEY 
110 BPL loopl 
120 RTS 
130 3NEXT 

140 FOR looped TO 31 

150 READ data 

160 loop?fcC00=data 

170 NEXT 

180 REPEAT 

190 CALL start 

200 REPEAT UNTIL 6ET 

210 UNTIL 1=2 

220 REM Face data 

230 DATA5,15,10,15,15,15,15,5 

240 DATA15,15,5,15,15,5,0,15 

250 DATA15,15,10,15,15,10,0,15 

260 DATA10,15,5,15,15,15,15,10 


Program III: EOR in action 


PROGRAM I 

30-50 Select options for assembler. 

60 Loads the Y register with 31. This is used as an 

offset which decrements from the last byte of 
the character’s position to the first byte of the 
character’s position. 

70 Reads a data byte from location &C00+Y. The 

last data byte is read first and the first data byte 
is read last. 

80 Stores the data byte in the video RAM at 

location &5400+Y. Again working from the 
end to the start location. 

90 Decrements the offset register, Y. 

100 Branches to do the next data byte if the Y 

register is still positive - in the range 0-127. This 
branch is not taken when the Y register 
becomes &FF (255 in decimal) - this means 
that the 32 data bytes have been stored in the 
video RAM, and Y has taken the values 31 to 0. 

It is easier to use an offset register which 
decrements from the end to zero than one which 
increments from 0 to the end because you do 
not need to use a CMP command or, in this 


case, CPY to test if all of the bytes have been 
copied. 

Program IA illustrates this, doing exactly the 
same as program I but starting at the first data 
byte and ending at the 32nd one. 

110 Returns to Basic. 

120 Ends assembler. 

130-160 Store data bytes for character into PAGE &C. 

170 Calls the machine code subroutine. 

180 ENDs the program. 

190-230 Data for the space invader - column by 
column, that is the first eight values define 
column 1, the next eight column 2 and so on. 
Remember &5400-&5407 are the memory 
locations of the first column. &5408 gives the 
start byte of the next column. 

PROGRAM II 

10-50 See program I description. 

60-100 The same as Program I except this time we 
display the data starting from the top left corner 
(&3000). 
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resultant byte will always be zero - the 
background colour, black. 

One byte which matches the 
background will not be very noticeable. 
But when two identical characters are 
directly on top of one another the result 
will be two invisible characters. Rather 
hard to see. 

Despite these disadvantages, many 
commercial games use this method to 
display characters on the screen. 

To show EOR in action try Program 
III. All this does is use the EOR method 
to display a face character on the 
screen. 

Initially the face appears in the centre 
of the screen. Since the background 
bytes are all zero and EORing any 
number with 0 leaves the number 
unchanged the data stored in the video 
RAM will be identical to the character 
data. 

Pressing a key causes the same shape 
to be placed on the screen again. Since 
EOR has been used to calculate the 
resultant bytes, the face disappears. 
This is because EORing a byte with 
itself results in zero - this was the 
original background colour. 

So from this we can see that calling 
the routine the first time displays the 
face and calling the same routine again 
erases the face. In other words, the 
character display routine is also a 
character delete routine - two for the 
price on one! 

It is for this reason that program 
writers use the EOR method to display 


shapes - it only needs one routine. Even 
Elite uses EOR when it plots lines on the 
screen. 

Try adding the following line to 
program III: 

175 VDU 31,8,14,ASCA" 

This displays the letter A underneath 
the face character. Any points of the 
letter A and the face which overlap 
produce a new colour, blue because of 
the effect EOR has. These points will be 
blue (colour 4), because, 3 (yellow face) 
EOR 7 (white letter A) = 4. 

Pressing Space deletes the face and 
leaves the letter A on the screen — this 
time the A will be in its original colour, 
white. 

• That's enough for this month . Next 
month we are going to move shapes 
around the screen . 


HdUlTD 
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10 REM PROGRAM IA 

130 JNEXT 

20 MODE 2 

140 FOR loop s 0 TO 31 

30 FOR pass=0 TO 2 STEP 2 

150 READ data 

40 PMB00 

160 loop?&C00 s data 

50 (OPT pass 

170 NEXT 

60 .start LDYI0 

180 CALL start 

70 .loop! LDAtcC00,V 

190 END 

80 .display STA&5400.Y 

200 REM Space Invader data 

90 INY 

210 DATA1,1,3,1,1,0,1,2 

100 CPYI32 

220 DATAB,3,1,3,2,3,B,0 

110 BNE loopl 

230 DATA0,3,2,3,1,3,B,0 

120 RTS 

24B DATA2,2,3,2,2,0,2,1 


Program I A: An alternative way of plotting a character 


110-140 

Add 32 to the screen location to move the start 


PROGRAM III 


location to the next character cell. This method 

30-50 

Set up assembler. 


involves self-altering code. By this I mean that 

60 

Sets offset register, Y, to 31. 


bytes are "poked” into the machine code 
routine by the machine code routine. In this 

70 

Reads data byte into the accumulator from 
location &C00+Y. 


example it adds 32 to the low byte of the screen 
address. 

80 

EORs the accumulator with the contents of the 
destination location of the byte - the result is 

150 

Branches if the addition doesn’t produce a 


left in the accumulator. 


carry. 

90 

Stores the accumulator in the video RAM at 

160 

Increments the high byte of the screen location. 


location &5400+Y. 


Again, this alters the machine code program by 

100 

Decrements the offset register, Y. 


adding one to the screen's high byte. 

110 

Branches if the character is not complete. 

170 

Returns to Basic. 

120 

Returns to Basic. 

180 

ENDs assembler. 

130 

Ends assembler. 

190-220 

Read and store the graphic data. 

140-170 

Read and store the face data. 

230-260 

Loops round until 100 space invaders have 

180 

Start of infinite loop. 


been displayed. 

190 

Calls the machine code routine to display the 

240 

Calls the routine which displays the space 
invader. 


face or delete the face. Remember that the same 
routine can display a character or delete a 

250 

Waits until a key is pressed. 


character - it’s a property of EOR. 

260 

End of FOR TO loop. 

200 

Waits until a key is pressed. 

270 

End of program. 

210 

Repeats the loop, since 1 will never equal 2. 

280-320 

Space invader graphic data. 

220-260 

Face graphic data. 
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EDWARDS 


Face 
up to 
it, you 
don't 
need to 
move 
one 

pixel at 
a time 


LAST month we found that moving objects around the Mode 2 screen — left and right 
— was quite easy. The main problem was how to delete the character. We solved it by 
using the EOR function, which provided us with a method of displaying and deleting 
a character by using just one routine. 

This month we’re going to move shapes up, down, left and right. In the process 
we’ll also find out how difficult it is to move a shape up and down the screen one pixel 
at a time. So far, to display characters we’ve used an indexing method when accessing 


the screen. 

The base location is used to indicate 
the start position of the character - its 
top left corner. Changing this base 
location allows us to move the object to 
other parts of the screen. 

As we saw last time, adding 32 to the 
base location moves an object right by 
one character cell, and subtracting 32 
from the base location moves the shape 
left one character cell. 

This may satisfy certain needs, but 
for most cases finer movement is 
needed. 

To do this we subtract or add eight to 
the base location. Subtracting eight 
moves the character left by two pixels 
and adding eight moves the character 
right by two pixels. 

Let me stress that adding or 
subtracting eight moves the base 
location to an adjacent column. 
Remember, each character row has 80 
columns of eight vertical bytes - each 
column byte corresponds to two pixels. 
That’s why the object moves two pixels 
when eight is added or subtracted. 

Moving an object left or right by one 
pixel is very awkward. This is because 
each memory location represents two 
pixels. 

It means that in addition to changing 
the base location, the character data 
must also be changed - shifted in the 
appropriate direction by one pixel. 

The easiest way to shift the data is to 
store the character data again - 
displaced by one pixel. 

The result is that twice as much 
memory is needed to store the character 
data. In Mode 2, memory is very 
valuable and so it’s always best to avoid 
repeating data. 

Software techniques can be used to 
shift characters across by one pixel, but 
these are very time consuming and so 
are rarely used - speed is considered 
more important than locks. 

Nearly all commercial games written 
in Mode 2 move characters left and right 
by two pixels, so don't get paranoid 
because you haven't got true pixel 
movement. It’s just not worth the extra 
memory and effort required, and in any 
case, moving two pixels at a time 
produces very smooth movement. 

If you don’t believe me try Program I. 
All you’ll see is a face character go 


across the screen - left to right. 

Program 11 allows you to move the 
face character left or right. The direction 
is controlled by pressing the Z and X 
keys - Z to move left and X to move 
right. 

We can now move a character left or 
right. The next thing to do is move it up 
or down. I’m afraid this is the most 
complex part of character movement. 

It’s simple to move a character up or 
down by one character line. To do this, 
640 must be subtracted or added to the 
base location. Adding 640 moves down 
one character line and subtracting 640 
moves up one line. Why 640? 

Each character line has 80 columns 
of eight bytes. So the next line begins at 
the previous line’s base location plus 
640 (80 * 8). 

The start locations of the first three 

-► 


10 REM PROGRAM II 
20 MODE 2 

30 FOR pass=0 TO 2 STEP 2 
40 PX=&B00 
50 [OPT pass 
60 .left LDA#19sJSR&FFF4 
70 JSR character 
80 LDA display'll 
90 SEC 
100 SBCI8 
110 STA display+1 
120 STA eor screen+l 
130 BCS no decrenent 
140 DEC display+2 
150 DEC eor_&creen+2 
160 .nojecreient JSR character 
170 RTS* 

180 .right LDAI19iJSR&FFF4 

190 JSR character 

200 LDA display+1 

210 CLC 

220 ADCI8 

230 STA display+1 

240 STA eor^screen+1 

250 BCC nojncreeent 

260 INC display+2 

270 INC eor screen+2 


Program II 
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Id REM PROGRAM I 

140 INC display+2 

270 READ data 

20 MODE 2 

150 INC eor_screen+2 

280 loop?fcC80=data 

30 FOR pass=0 TO 2 STEP 2 

160 .no.increient JSR character 290 NEXT 

40 PX=&B00 

170 RTS 

300 CALL character 

50 COPT pass 

180 .character LDYI31 

310 FOR loop=l TO 75 

60 .right LDA019:JSR&FFF4 

190 .getbyte LDAIC00.Y 

320 CALL right 

70 JSR character 

200 ,eor_screen EQRfc5300,Y 

330 NEXT 

80 LDA display+1 

210 .display STA&5300.Y 

340 END 

90 CLC 

220 DEY 

350 REM Face data 

100 ADCI8 

230 BPL getbyte 

360 DATA5,15,10,15,15,15,15,5 

110 STA display+1 

240 RTS 

370 DATA15,15,5,15,15,5,0,15 

120 STA eor_screen+l 

250 1NEXT 

380 DATA15,15,10.15,15,10,0,15 

130 8CC no increment 

260 FOR loop : 0 TO 31 

390 DATA10,15,5,15,15,15,15,10 


---- 

- __ ■ 

Line No. 


character right by two pixels. 

10-50 Enter assembler. 

160 

Display the face in its new screen position. 

60 Main entry point. This line executes a *FX 19 170 

End of the main routine. 

command (wait for vertical sync.). Used as a 180-240 

Subroutine to display the face on the screen. 

time delay to ] 

aroduce smooth movement 250 

Exit assembler. 

without flicker. 

260-290 

Read and store the face data in page &C. 


70 


80-150 


Delete the face character. Remember, calling 
an EOR character routine the second time 
deletes the character. 

Add eight to the base address - move the 


300 

310-330 

340 

350-390 


Put face on the screen - initial set-up. 
Move the face right through 75 positions. 
End of program. 

Face data. 


Description of Program I 


280 .nojncreaent JSR character 
290 RTS* 

300 .character LDYI31 
310 .getbyte LDAfcC00,Y 
320 .eorjcreen EOR&5300,Y 
330 .display STAk5300,Y 
340 DEY 

350 BPL getbyte 
360 RTS 
370 ]NEXT 

380 FOR loop=0 TO 31 
390 READ data 
400 loop?*C00*data 
410 NEXT 
420 X=0 

430 CALL character 
440 REPEAT 

450 IF INKEY(-98) AND X>0 CALL left 
iM-l 

460 IF INKEY(-67) AND X<76 CALL rig 
htsX=X+l 
470 UNTIL 1=2 
480 REM Face data 
490 DATA5,15,10,15,15,15,15,5 
m QATA15,15,5,15,15,5,0,15 
510 DATA15,15,10,15,15,10,B,15 
520 DATA10,15,5,15,15,15,15,10 


Line No. 
10-50 
60 
70 

80-150 

160 

170 

180 

190 

200-270 

280 

290 

300-360 

370 

380-410 

420 

430 

440 

450 


460 


470 

480-520 


Enter assembler. 

Wait for vertical sync. 

Delete the face. 

Subtract eight from the base location - move 
the character left by two pixels. 

Display the character in it’s new position. 

End of routine. 

Wait for vertical sync. 

Delete the face. 

Add eight to the base location - move it right by 
two pixels. 

Display the face. 

End of routine. 

Subroutine to display the face on the screen. 
Exit assembler. 

Read and store graphic data. 

X coordinated. 

Display the character. 

Start of an infinite loop. 

Check if Z is pressed. Move the character left as 
long as the X coordinate remains on the same 
character row. And then decrease the X 
coordinate. 

Check if X is pressed. Move the character right 
as long as the X coordinate remains on the 
same character row. And then increase the X 
coordinate. 

Loop round. 

Face data. 


Description of Program II 
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Line No. 
10-50 
60 
70 

80-160 

170 

180 

190 

200 

210-290 

300 

310 

320-380 

390 

400-430 

440 

450 

460 

470 


480 


Enter assembler. 

Wait for vertical sync. 

Delete character. 

Subtract &280 from the base location - move 
the character up one line. 

Display the character. 

Exit. 

Wait for vertical sync. 

Delete the character. 

Add &280 to the base location — move the 
character down one line. 

Display the character. 

Exit. 

Subroutine to display the character on the 
screen. 

Exit assembler. 

Read and store the face data. 

Y coordinated. 

Display the face. 

Start of loop. 

Check the : key. Move the character up if the 
key is pressed and the character remains on the 
screen. And then increment the Y coordinate. 
Check the / key. Move the character down if the 
key is pressed and the character remains on the 
screen. And then decrement the Y coordinate. 


le 

REM PROGRAM III 

20 

MODE 2 

30 

FOR pass=0 TO 2 STEP 2 

40 

PX=i800 

50 

[OPT pass 

60 

.up LDA#19:JSR&FFF4 

70 

JSR character 

80 

LOA display+1 

90 

SEC 

100 

SBCI&80 

110 

STA display+1 

120 

STA eor screen+1 

130 

IDA display+2 

140 

SBCI2 

150 

STA display+2 

160 

STA eorscreen+2 

170 

JSR character 

180 

RTS 

190 

.down LDAI19;JSRIFFF4 

200 

JSR character 

210 

LDA display+1 

220 

CLC 

230 

ADCI&80 

240 

STA display+1 

250 

STA eor screen+1 

260 

LDA display+2 

270 

ADCI2 

280 

STA display+2 

290 

STA eor_screen+2 

300 

JSR character 

310 

RTS 

320 

.character LDYI31 

330 

.getbyte LDAfrC00,Y 

340 

.eorscreen EOR63000,Y 

350 

.display STAIc3000,Y 

360 

DEY 

370 

BPL qetbyte 

380 

RTS 

390 

1NEXT 

400 

FOR loop=0 TO 31 

410 

READ data 

420 

loop?&C00=data 

430 

NEXT 

440 

Y=0 

450 

CALL character 

460 

REPEAT 

470 

IF INKEY(-73) AND Y>0 CALL up:Y 

■Y-l 


480 

IF INKEY(-105) AND Y<31 CALL do 

wn:Y=Y+l 

490 

UNTIL 1=2 

500 

REM Face data 

510 

DATA5,15,10,15,15,15,15,5 

520 

DATA15,15,5,15,15,5,0,15 

530 

DATA15,15,10,15,15,10,0,15 

540 

DATA10,15,5,15,15,15.15,10 


Program III 


Description of Program HI 


From Page 104 

character rows are &3000, &3280 and 
&3500 respectively. Each increases by 
&280 as you go down the screen. The 
clever among you will know that 
&280=640. 

Also notice that the difference in 
memory locations between the same 
position on ANY adjacent character 
lines is always &280. 

Program III allows you to move a 
character up and down the screen, one 
line at a time. Use / to move the 
character down and : to move it up. 

Subtracting or adding 640 from the 
base location produces character 
movement up or down. What do we do 
if we want to move the character up or 
down by one pixel? There is no simple 
solution. 

To simplify things we’ll forget moving 
a whole character and move a single 
byte instead. First we’ll move a byte 
down the screen. 

You’ll find it a lot easier to 
understand the following information if 
you read it in conjunction with Diagram 
I. 

Initially, the screen location we store 
the byte in is &3000 - the top left of the 
screen. To move the byte down by one 
pixel we increment the screen location 
by one - to &3001. All goes fine. 


incrementing the location until we reach 
location &3007 - the bottom of the 
character row. 

At this point incrementing the screen 
location to &3008 moves it to the top of 
the next column on the same line. In 
fact, the location we want to store the 


COLUMN 



0 

1 

2 

78 

79 

HIHEH 

<(3866 

<3008 

<3010 

.. <3270 

<3278 


<3011 

<3009 

<3011 .. 

.. <3271 

<3279 


<3012 

1(390 A 

<3012 .. 

<3272 

<327A 

RON 0 

<3003 

<300B 

<3013 

<3273 

<327B 


<3104 

<300C 

<3014 

.. <3274 

<327C 


<3003 

<3000 

<3013 ,, 

<3275 

<3270 


<3006 

<300E 

<3016 

.. <3276 

<327E 


<3007 

<300F 

<3017 

<3277 

<327F 


<3280 

<3288 

<3290 

<34F0 

<34FB 


<3281 

<3289 

<3291 

<34F1 

<34F9 


<3282 

<328A 

<3292 .. 

<34F2 

<34FA 

RON 1 

<3283 

<3280 

<3293 

.. <34F3 

<34FB 


<3284 

<328C 

<3294 .. 

<34F4 

<34FC 


<3285 

<3280 

<3295 

<34F5 

<34FD 


<3286 

<328E 

<3296 .. 

. <34F6 

<34FE 


<3287 

<32BF 

<3297 

.. <34F7 

<34FF 


<3500 

<3508 

<3518 .. 

<3770 

<3778 


<3501 

<3509 

<3511 

.. <3771 

<3779 


<3502 

<35BA 

<3512 .. 

.. <3772 

<377A 

ROM 2 

<3503 

<350B 

<3513 .. 

<3773 

<377B 


<3504 

<350C 

<3514 .. 

. <3774 

<377C 


<3505 

<3500 

<3515 .. 

. <3775 

<3770 


<3506 

<350E 

<3516 .. 

. <3776 

<377E 


<3507 

<3S0F 

<3517 .. 

. <3777 

<377F 


Diagram I 
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10 REM PROGRAM IV 

100 ANDI7 

190 LDA display+2 

20 REM By Kevin Edwards 

110 CMPI7 

200 ADCI2 

30 MODE 2 

120 BES botto«_of_coluan 

210 STA display+2 

40 FOR pass=0 TO 2 STEP 2 

130 INC display^l 

220 RTS 

50 PX=iB00 

140 RTS 

230 3NEXT 

60 (OPT pass 

150 .botto*_of_colimn LDA display+1 

240 FOR loop=l TO 100 

70 .start LDAI63 

160 CLC 

250 CALL start 

80 .display STA13000 

170 ADCI&79 

260 REPEAT UNTIL GET 

90 LDA display+1 

180 STA display+1 

270 NEXT 


byte in - to move it down one pixel - is 
&3280 and not &3008. 

We now have a problem. How can we 
tell if we increment the screen location 
by one or add a much larger number to 
it? 

The clue is that we increment the byte 
by one only if the current screen 
location is not at the bottom of the 
character row and we add &279 if it is at 
the bottom of the character row - this 
moves the byte to the top of the next 
character row. 

But how do we know if a screen 
location is at the bottom of the character 
row? The answer can be found by using 
the logical operator AND. 

Figure I is a list of some of the 
locations at the bottom of character row 
0. Each location is followed by its 
binary equivalent. 

Have you noticed a pattern? If not, 
take a look at the binary patterns for the 
low bytes of the screen locations. 

The answer is that the three least 
significant bits of the low byte of the 
screen address are all set to 1. 

So if bit 0= 1 AND bit 1 = 1 AND bit 
2=1 the screen location is at the bottom 
of the character row. 

In practice, we AND the screen 
location with 7 — we get seven from 
4+2+ 1, bit 2,1 and 0 being set. If the 


resultant byte is seven then the First 
three bits of the low byte must be set. In 
which case the location is at the bottom 

Screen high 

1 OH 

location byte 

byte 

13007 = X 00110000 

00000111 

&300F = X 00110000 

00001111 

13017 = X 00110000 

00010111 

i(301F = X 00110000 

00011111 

1(3027 = X 00110000 

• i 

00100111 

• ' 

. « 

1(3277 s X 00110010 

• 

01110111 

k327F = X 00110010 

01111111 


Line No. 
10 60 

Enter assembler. 

70 

Load the accumulator with the byte to be stored 
in the video RAM. 

80 

Store the accumulator in the video RAM - 
display the byte (two white pixels). 

90-110 

Check if the location of the byte displayed is at 
the bottom of a character row. 

120 

Branch if it is at the bottom of a character row. 

130 

Increment the screen location - move the byte 
down one pixel. 

140 

Exit. 

150-210 

Add &279 to the screen location - this moves 
the byte to the top of the next character row. 

220 

Exit. 

230 

Exit assembler. 

240 

Start of loop. 

250 

CALL the routine. 

260 

Wait until a key is pressed. 

270 

End of loop. 

Description of Program IV 


of a character row. In assembly, the 
required check would look something 
like this: 


using the AND function. Consider the 
following locations which are all at the 
top of character row 1: 


.down pixel LDA screenlow 
AND 17 
CMP 17 

BNE not_at_botto« 
LDA screenlow 
CLC 

ADC Ifc79 
STA screenlow 
LDA screenhigh 
ADC 12 

STA screenhigh 
JMP rest_of jrograe 
.not_at_botto« INC screenlow 
.rest^ofjrogram _ 


Figure I 


Program IV moves a byte down the 
screen one pixel at a time. Press a key to 
continue the movement. Moving shapes 
up the screen by a pixel is very similar to 
moving it down. 

A byte can be moved up by 
decrementing the screen address. When 
the byte reaches the top of a character 
row a much larger number must be 
subtracted from the screen location - 
this larger number is &279. 

Now we have to find a way of testing 
whether a screen location is at the top of 
a character row. Again, we do this by 


Screen 

location 


high 

byte 


low 

byte 


Sc3280 = X 00110010 
k3288 = X 00110010 
&3290 = X 00110010 
&329B = X 00110010 10011000 
&32A0 = X 00110010 


&34F0 = X 00110100 
&34F8 = X 00110100 


11110000 

11111000 


???????? ?????00B 


Again bits 0,1 and 2 of the screen 
address low byte give us the answer - 
they are all zero this time. 

So if bit 0=0 AND bit 1=0 AND bit 
2=0 the screen location is at the top of a 
character row. 

In machine code we AND the low 
byte with 7, and if the result is 0 then the 
screen location is at the top of the 
character row, otherwise the location is 
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AND GIVING 
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THE OPUS 3" DISC DRIVE 
NOW ONLY 

£199195 



WITH A DOUBLE DENSITY DISC 
INTERFACE (WORTH £100) 

FREE. 
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Acorn compatible double density disc interlace. That’s 
over ^100 off the normal retail price. 
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all our drives. 
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at another position in the character row. 

Here is a check routine for moving a 
screen location up by one pixel. 

.up pixel LDA icreenlow 

AND *7 

BNE not_at_top 
LDA screenlow 
SEC 

SBC 1*79 
STA screenlow 
LDA screenhigh 
SBC 12 

STA screenhigh 
JhP rest.of jirogra* 
.not_at_top DEC screenlow 
.rest_of jirogra* 

Program V moves a byte up the 
screen one pixel at a time - the reverse 
of Program IV. Press a key to continue 
the movement. 

It’s rather complex isn’t it? Wait until 
you’ve got to do this for a complete 
character! 

That’s enough for this month. Try 
and absorb as much of it as you can 
before the next instalment. 


10 REM PROGRAM V 
20 REM By Kevin Edwards 
30 MODE 2 

40 FOR pass=0 TO 2 STEP 2 
50 PX=S<B00 
60 [OPT pass 
70 .start LDAI63 
80 .display STA&7D87 
90 LDA display+1 
100 ANDI7 

110 BEQ top_of_colu»n 
120 DEC display+1 
130 RTS 

140 .top_of^column LDA display+l 
150 SEC ’ 

160 SBCI&79 

170 STA displav+1 

180 LDA display+2 

190 SBCI2 

200 STA display+2 

210 RTS 

220 3NEXT 

230 FOR 1oop = 1 TO 100 
240 CALL start 
250 REPEAT UNTIL BET 
260 NEXT 


Line No. 
10-60 
70 


80 

90-100 


110 

120 


130 

140-200 


210 

220 

230 

240 

250 

260 


Enter assembler. 

Load accumulator with 
byte to be stored in video 
RAM. 

Store accumulator in video 
RAM - display byte. 
Check if location of byte 
displayed is at top of a 
character row. 

Branch if it is at top of a 
character row. 

Decrement the screen 
location - move byte up one 
pixel. 

Exit. 

Subtract &279 from screen 
location - this moves the 
byte to bottom of previous 
character row. 

Exit. 

Exit assembler. 

Start of loop. 

CALL the routine. 

Wait until a key is pressed. 
End of loop. 


Description of Program V 



Your submarine is being attacked by wave after wave of 
enemy helicopters armed with bombs, depth charges and 
ASGROC (Anti-Submarine Guided ROCkets), the only 
way to survive is to blast them out of the sky before they 
can get you - but look out for crashing helicopters, 
drifting mines and Sonar Subs - and even the fish are 
dangerous ... 

A game of skill, speed and sheer nerve against rapidly 
increasing odds, from Tomorrows Dream Software. 

Fast 100% Machine Code action utilising full colour Mode 
2 graphics, sound effects & music, joystick option, High 
Score table and demo mode, only £6.50 direct from TDS. 


TITAN 

The debugging monitor utility for machine code programs on the BBC B. 
Single stepping through RAM and ROM - including operating system 

* Intelligent memory mover 

* Single step through graphics routines 

* Breakpoints in RAM and ROM 
Microsecond timer 

* Intelligent masked string search routine 

Plus:- 'Front Panel' display, OSCLI commands available within debugger, 
conditional breakpoints at relative branch instructions, display of four 
memory windows continuosly updated during single stepping, arithmetic 
operators + - x 4- , output to printer, ASCII dump, hex dump, dis¬ 
assembly, block fill, plus much more. 

With complete instruction manual, only £1 Oon tape, £12 on disc from TDS 

Written any good software? 

We pay top rates for original programs. 



Please send me Sub Strike on tape (£6.50)/disc (£8.50) 
TITAN on tape (£ 10)/disc(£12) 

Please specify DFS when ordering disc versions. 

I enclose a cheque/PO for £ payable to 

Tomorrows Dream Software. 

Name. 

Address (BLOCK LETTERS). 


Send this coupon with your cheque/PO to: TDS, Richmond 
House, IB Sydenham Road, Cotham, Bristol BS6 5SH 
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THIS month we’re going to look at 
software sprites in Mode 2. Sprites are 
large characters (sometimes multi¬ 
coloured) which can be moved around 
the screen by very simple commands. 

They are normally controlled by 
hardware, but with clever programming 
techniques they can be simulated with 
software routines. 

All the user has to define is the size of 
the sprite, its position and the data that 
corresponds to its shape and colour. 

Hardware sprites offer automatic 
collision detections and have a priority 
system. They also take up virtually no 
processing time - in other words, 
they're very fast. And for most 
applications where they’re used - such 
as games - speed is essential. 

Since sprites are separate from the 
normal screen display, no background 
data is lost when they pass over other 
objects. 

They don’t even destroy their own 
kind. 

The BBC Micro, unfortunately, does 
not have any hardware sprites. 
Programmers have to imitate them 
using software. The result can never be 
as good as the real thing, but is suitable 
for most purposes. 

The main difference is speed. 
Software sprites take a lot of processing 
time in updating the video RAM. 
Another problem is that the display may 
flicker, depending upon when the sprite 
is displayed and how large it is. 

To explain this further we must look 
at the way television sets and monitors 
display pictures. 

Every fiftieth of a second the screen 
display is refreshed (updated). The 
beam of electrons that creates the 
picture, called the raster, scans across 
the screen displaying the picture from 
left to right, working its way down the 
screen. 

When it reaches the bottom right 
corner it moves back to the top left and 
starts all over again - one fiftieth of a 
second later. 

The time taken to move from the 
bottom right to the top left is known as 
the re-trace period. 

The best time to reposition a software 
sprite is during the re-trace period, when 
the screen is not being updated. This is 
easier said than done because the 
re-trace period is very short. 

If you update a software sprite at the 
same time as the raster displays it the 
screen will flicker. 

For example, if you’re half way 
through updating a sprite and the raster 
reaches the point on the screen where 


Summon up 
some spritely 
characters 


the sprite is to be displayed, only half of 
it will appear - the other half hasn’t been 
finished yet. 

If this is repeated 50 times a second a 
horrible flashing character will result - 
I’m sure you’ve seen examples of this. 

Fortunately we can wait for the start 
of the re-trace period by issuing a *FX 
19 command (OSBYTE 19). 

The usual procedure used to update a 
software sprite is to execute a *FX 19 


command, erase the sprite and 
redisplay it at its new position. This will 
reduce the flicker. In fact, the display 
and delete routines are the same. This is 
because EOR has been used to display 
the sprites - see the March issue of The 
Micro User for more details about 
EOR. 

If, however, a large sprite is being 
moved near the top of the screen, 
flickering will occur even if the above 


[Line No. 

30 Defines the screen address for 
the top of the column. 

40 Defines the start address for 
the data which is stored in the 
column. 

60 Defines the height of the 
column (in pixels). 

80-100 Enter the assembler and 
assemble the code at &2E00. 
110-160 Store the parameters in zero 
page. 

170-180 Copy the column start address 
from &76,&77 into &70.&71 
- this is used in later 
programs. 

190 Load the X register with the 
column height then load the 
offset register Y (for the 
indirect addressing) with 0 - 
the offset is always left at 0. 
200-210 Read the screen byte. EOR it 
with the data byte and store it 
back in the video RAM. 
220-230 Increment the data pointer by 
one. 

240-290 Move the screen pointer down 
one pixel - see last month’s 
article. 

300 Decrement the height register, 

X, and repeat the previous 
steps if the column isn’t 
complete. 

340 Back to Basic. 

350 Exit assembler. 

360 Automatically tests the 

routine. 

Program I Description of Program I 


10 REM Colusn poke routine 
20 REM By Kevin Edwards 
30 screen=lc3108 
40 data=&0000 
60 heiqht=12B 
70 NODE 2 
80 HIMEH a l<2E00 
90 FORL«0TO2STEP28 P%=HINEM 
100 [OPTL 

110 .start LDAiheightsSTASc75 
130 LDAtdata MOD 256:STA*72 
140 LDAtdata DIV 256:STAl<73 
150 LDAIscreen MOD 256:STAfc76 
160 LDAIscreen DIV 256:STA*77 
170 .«ain part LDA*76:STA*70 
180 LDAl77sSTA&71 
190 LDYt0:LDXfc75 

200 .coluin LDA(fc7B)'VcE0R(t72),Y 
210 .onto_screen STA(fc70),Y 
220 .incre«ent_data INC*72:BNE no^h 
i ah 

230 INC&73 

240 .no^high LDA&70:AND47 
250 CMPI7 jBNE not.at.bottoi 
260 CLC:LDAt70:ADCH79:STA&70 
270 LDA*7i:ADCt2:STA*71 
280 JMP check,end_of_coluiin 
290 .not atjottoa INC*70 
300 .check_endj)f^colu»n DEX:BNE co 
luan 
340 RTS 
350 3NEXT 
360 CALL start 
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procedure is followed. This will be 
because the raster has completed the 
retrace and is now displaying the top of 
the new screen where the large sprite is 
still being updated - it takes longer to 
display a large sprite than a small one. 

One way to avoid this is to execute 
*FX 19, wait a while, and then update 
the sprite. The time delay should be long 
enough to allow the raster to pass the 
base of the sprite. Now it is safe to 
update the screen memory. 

As you can see, it’s very awkward to 
produce fast software sprites without 
flicker. Consider the case where you 
have 10 sprites moving around the 
screen. If you used *FX 19 before you 
updated each one the program would 
slow down. So the only way to speed it 
up is to miss a few *FX 19s. The 
obvious result is flicker. You have to 
trade off speed versus flicker. 

Now we’ve got that off our chests 
we’ll get down to implementing sprites 
on the BBC Micro. 

Last month we saw how a byte could 
be moved vertically. One program 
moved the byte up the screen and the 
other moved it down. In this article we 
are only interested in moving a byte 
down the screen. 

The first program, Program I, allows 
a set of data to be displayed vertically 
down the screen. The method used to 
move to the next byte down the screen 
was described last month. 

So far we’ve never used indirect 
addressing. Program I uses post- 
indexed indirect addressing to read a 
byte from the video RAM, EOR it with 
the data byte and write it to the screen 
again. Remember, EORing the screen 
and data bytes allows us to use one 
routine for displaying and deleting a 
sprite. 

Indirect addressing works like 
absolute addressing except that the 
action address is given by the contents 
of two consecutive zero page locations 
which are specified. 

The apparently “missing” lines in 
Program I have been filled in Program 
II, which allows a sprite of any size to be 
displayed anywhere on the screen. 

The routine starts at the top left 
corner of a sprite and works its way 
down, one pixel at a time. On its way it 
copies a data byte into the screen 
address being accessed, thus displaying 
part of the sprite. 

When it reaches the base of the sprite 
it starts again at the top, this time to the 
right of the previous start address. 

Remembering the top location of 


10 REH Simple, slow sprite routine 
20 REH By Kevin Edwards 
30 screen=i3100 
40 data=&8000 
50 width=10 
60 height=64 
70 MODE 2 
80 HlHEH=i2E00 
90 FORL=0TO2STEP2:PX=HIHEH 
100 COPTL 

110 .start LDAiheight8STA&75 
120 LDAiwidth: STAI*74 
130 LDAidata HOD 256:STA*72 
140 LDAidata DIV 256:STAi73 
150 LDAIscreen HOD 256sSTAfc76 
160 LDAIscreen DIV 256:STA*77 
170 .nainjart LDAI<76:STA&70 
180 LDAI(77:STAIc71 
190 LDYI0:LDX&75 

200 .colunn LDA(fc78),YsE0R(i72),Y 
210 .onto screen STA(170),Y 
220 .increnent.data INC472:BNE no..h 
igh 

230 INC&73 

240 .no.high LDA*70:ANDI7 
250 CHPI7:BNE not .atpottos 
260 CLC:LDA&70:ADCI&79;STA&70 
270 LDAIt71: ADCi2: STAIc71 
280 JMP check > _end - of.cQluan 
290 .not_at_bottoi INCIc70 
300 .check_end_of_coluin DEXsBNE co 
luin 

310 CLC: LDA&76: ADCIBs STAt(76: BNE tes 
t_end_coluin 
320 INC&77 

330 .test end_colu*n DECfc74;BNE ®ai 
n_part 
340 RTS 
350 JNEXT 
360 CALL start 

Program II 

each column and adding 8 to it provides 
a simple method of finding the start 
address for the new column. 

In other words, the column routine, 
Program I is repeated over and over 
again, with the start address 8 bytes 
further on in memory each time - two 
pixels to the right. 

This means that the data for the sprite 
must be stored sequentially column by 
column. A data pointer keeps track of 
the data item being displayed - 
locations &72 and &73 point to the next 
byte to be displayed. 

The dimensions of the sprite are 
defined in lines 50 and 60. The width 
corresponds to paired pixels, whereas 
the height corresponds to single pixels - 


Part four 

HDEUTD 

WRITE 

MACHINE 

CODE 

GAMES 

By KEVIN 
EDWARDS 


Program II is the same as Program I 

with the following additional lines: 

50 Defines the width of the sprite 
(in paired pixels). 

120 Copies the sprite’s width into 
zero page. 

310-320 Add 8 to the column’s 
previous start address - this 
moves the column right by 
two pixels. 

330 Tests to see if all of the 
columns have been displayed. 
Branch if they haven’t. 


Description of Program II 


remember each byte is two pixels wide 
and one pixel high. 

Line 30 specifies the screen address 
for the top left corner of the sprite. This 
must be between &3000 and &7FFF — 
the start and end of the video RAM in 
Mode 2. 

Line 40 defines the start address of 
the sprite data. This data corresponds to 
the shape and colour of the sprite. 

Programs I, II and III display data 
from &8000 onwards. &8000 is the 
start of the Basic ROM and so produces 
random shapes and colours on the 
screen. 

Program III uses the same techniques 

-► 
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as Program II but in a more efficient 
way. The speed increase is about 30 per 
cent. 

Software sprite routines tend to vary 
considerably, depending on the size and 
movement of the sprites used. Very fast 
routines are usually tailor made for the 
sprites being used. The sprite routines 
given (Programs II and III) are purely 
for general use. 

The aim of them all is to be as fast and 
efficient on memory as possible. One 
way to speed them up is to locate the 
routine in zero page. 

The 6502 can execute zero page 
programs quicker because addressing 
modes for zero page are quicker than 
absolute addressing. For example, INC 
&4000 takes longer to execute than 
INC &70. Although the time difference 
is small, when executed several hundred 
or thousand times it becomes signifi¬ 
cant. 

Program IV uses a faster sprite 
routine to display a yellow face at the 
top of the screen. 

Lines 50 and 60 inform the routine to 
display a sprite the same size as a 
character - 4 bytes by 8. 

The problem with the sprite routines 
we’ve developed up to now is that 
they’re not very user-friendly when it 
comes to specifying the position of the 
sprite. 

At the moment you specify the screen 
location for the top left corner of the 
sprite. It would be much easier if you 
could specify the X and Y coordinates 
of the sprite and let a routine calculate 
the screen address for you. 

The X axis consists of 80 columns 

-► 


10 REM Faster sprite routine 

200 LDA476:AND»7:TAY 

20 REM By Kevin Edwards 

210 .colunn LDA&FFFF,X:EOR(&7B),Y 

30 screen=&3100 

220 .onto.screen 8TA(170),Y 

40 data=l<8000 

230 INXiBEB inc.data.high 

50 Hidth=20 

240 .end.checks 1NY:CPX178:BEQ end. 

60 height=48 

of.coluan 

70 MODE 2 

250 CPY48:BNE coluan 

80 HIMEM42E08 

260 LDAt70:ADCIt7F:STAfc70 

90 FORL=0TO2STEP2iPX'HIMEM 

270 LDA&71:ADCI2:STA171 

100 COPTL 

280 LDY40:BEQ coluan 

118 .start LDAtheiqht:STAfc75iSTAIt78 

290 .inc.data.high INC coiuan-t-2:JMP 

120 LDAiwidth:STAI<74 

end.checks 

130 LDAIdata HOD 256:STAcolu«n+l 

300 .end.of.coluan CLC:LDAtc76:ADC*8 

140 LDAIdata DIV 256:STAcoluan+2 

:STAIt76:BCC no.high: INC177 

150 LDAtscreen MOD 256:STAIt76 

310 .no.high CLC:LDAtc78:ADCI<75:STAIc 

160 LDAIscreen DIV 256:STAi77 

78 

170 .user.entry LDX40 

320 DECfc74:8NE aain part 

180 .aain'part LDA676:AND(lFB:STAfc7 

330 RTS 

0 

340 3NEXT 

190 LDAU7sSTAlc71 

350 CALL start 



30-60 Define the sprite parameters. 

80-100 Enter assembler. 

110-160 Copy sprite parameters into other parts of 
memory. Two of the bytes are stored within the 
program itself, and the others are put in zero page. 

170 Data offset register = 0. 

180-190 Copy column start address into &70,&71. The 
low byte being the top of the current character 
column (AND &F8). 

200 Loads the offset register with the screen low byte 
ANDed with 7 - to get the offset from the top of 
the character column. 

210-220 Read the data byte, EOR it with the screen byte 
and store it back in the video RAM. 

230 Increments the data offset register. If the X 
register is zero, branch, so that the data pointer 
high byte can be incremented. 

240 Increments the screen memory address offset 
register. Check if the end of the column has been 
reached. If it has, the branch is taken. 

250 Checks to see if the start of the next character row 
column has been reached. Branch if it hasn’t. 

260-280 Add &280 to the screen address - to move down 
to the next character row. 

290 Increments the data pointer high byte and 
continues with the rest of the column. 

300 Adds eight to the column’s start address - the top 
of it. This moves the start address right by two 
pixels. 

310 Changes the data offset stop pointer so that the 
end of the next column will be terminated 
correctly. 

320 Checks to see if all of the columns have been 

displayed. Branch if they haven’t. 

330 Exits to Basic. 

340 Exits assembler. 

350 Tests program. 


Description of Program III 
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IB REM Faster sprite routine 

240 .end.checks INY:CPXi.78:BEQ end 

20 REM By Kevin Eduards 

ot.coluan 

30 screen=&3100 

250 CPYI8:BNE coluan 

40 data=fcC00 

260 LDAJ.70iADCIJ.7FiSTAI.70 

50 uidth=4 

270 LDAJ.71iADCI2iSTAJ.71 

60 heights 

280 LDYI0:BEQ coluan 

70 MODE 2 

290 ,inc.data_high INC coluan*2:JMP 

80 HIMEM=t.2E00 

end checks 

90 FORL=0TO2STEP2:PX=HIMEM 

300 .end of coluan CLCsLDAJt76:ADCIB 

100 [OPTL 

:STAS.76:6CC no_highiINCt.77 

110 .start LDAIheiqht;STAI<75:STA&78 

310 .no high CLC:LDAJ.7B:ADCJ,75:STAJ. 

120 LDAlKidth:STAl74 

78 

130 LDAIdata MOD 256:STAcoluan+l 

320 DECJ.74:BNE aain.part 

140 LDAIdata DIV 256:STAcoluan+2 

330 RTS 

150 LDAIscreen MOD 256:STAJ.76 

340 3NEXT 

160 LDAIscreen DIV 256:STAI<77 

350 FORLX-0 TO 31 

170 .user entry LDXI0 

360 READ LX?data 

180 .aainjart LDAJ.76iANDUF8:STAl7 

370 NEXT 

0 

380 CALL start 

190 LDAJ.77iSTAt.71 

390 DATA5,15,10,15,15,15,15,5 

200 LDAt.76: ANDI7: TAY 

400 DATA15,15,5,15,15,5,0,15 

210 .coluan LDMFFFF,X:E0R(17B),Y 

410 DATA15,15,10,15,15,10,0,15 

220 .onto.screen STA(J.70),Y 

420 DATA10,15,5,15,15,15,15,10 

230 INX:BEQ inc.data_high 



Program IV 


Program IV is the same as Program III 
with the following additions or changes: 
30-60 The sprite parameters have 
been changed to display a 8 by 
4 byte sprite at location 
&3100 on the screen - the 
data starts at &C00. 

350-370 Read and store the sprite data 
into page &C. 

390-420 The sprite data - a smiling 
face. 


Description of Program IV 


Memory map for the sprite routines: 
&70,&71 Screen address pointer. 
&72,&73 Data pointer. 

674 Width of sprite, decremented 
each time a column is 
displayed. 

675 Height of the sprite in pixels. 
&76,&77 Copy of the column start 

address - the top of the 
current column. 


IB REM Screen location calculator, 
20 REM Using screen X and V co-ord 
s. 

30 REM Origin - top left corner. 

40 REM Uses O.S for data tables. 

50 REM By Kevin Edwards 
60 M0DE7: HIMEM=»tt7000 
70 FQRL=0TQ2STEP2:PX=HIHEM 
80 COPTL 

90 .calc Joe LDAIUBsSTAkBI 
100 LDA«0:STA&82 
110 TYA:ANDI7:STA180 
120 TYAs LSRAs LSRA:LSRA:ASLAs TAY 
130 TXAsASIA:R0L&82!ASLA:RQL&82 
140 ASLA:R0Lic82 
150 ADCIe80: ADC&C376, Y: STAttBB 
160 LDA&82:ADC&81:ADC&C375,Y:STAfc81 
170 RTS 
180 1NEXT 
190 REPEAT 

200 INPUT' '“Enter X co-ordinate",XX 
210 IF XZ<0 OR XX)79 THEN VDU7:PRIN 
T'“X aust be in the range 0-79 !**:GOT 
0 200 

220 INPUT'“Enter Y co-ordinate",YX 
230 IF YZ<0 OR YX>255 THEN VDU7:PRI 
NT'"Y aust be in the ranqe 0-255 !":6 
0T0 220 

240 CALL ealejoe 

250 PRINT # “Location =*V?M1*256*? 

m 

268 UNTIL 1=2 


Line No. 
60-80 
90 

100 


110 

120 


130-140 


150 


160 


170 

180 

190-260 


Enter assembler. 

Stores Mode 2 screen start address high byte in 
&81. 

Stores 0 in the workspace. This is used to 
accommodate any overflow that occurs when X is 
multiplied by 8. 

Puts Y AND 7 into the screen address low byte. 
Calculates (Y/8)*2. The result of Y/8 is multiplied 
by 2 to allow us to make use of the ROM 
multiplication table - this starts at &C375 and 
consists of 32 entries of an &280 multiplication 
table. Each entry in the table is stored in pairs - 
high byte then low byte. 

Calculate X*8. The three most significant bits of 
the result are held in bits 0 to 2 of location &82 the 
workspace. 

Adds the screen low byte to the result of X*8. 
Then adds the low byte of the &280 multiplication 
table to the result. This is then stored in location 
&80. 

Adds the high byte of X*8 to the screen address 
high byte. Then adds the high byte of the &280 
multiplication table and stores the result in 
location &81. 

Back to Basic. 

Exit assembler. 

Accept valid input for two screen co-ordinates 
and print the result. 


Description of Program V 


Program V 
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(0-79) and the Y axis has 256 rows 
(0-255) - see Figure I, page 74 in the 
February issue of The Micro User. If we 
use the top left corner as the origin we 
can use the following equation to 
calculate the screen location. 

Iocation=ti3000+(X*B)+!(2B0*IY 01V 8) + (Y 
AND 7) 

As you can see, it’s quite a complex 
equation. The machine code equivalent 
is given in Program V. 

When you RUN the program you’ll 
be asked to enter the X and Y 
coordinates of the sprite’s position - 
remember the origin is the top left 
corner of the screen. On entering these 
the screen address will be calculated and 
displayed. 

On entry to the routine the X register 
holds the X coordinate of the sprite and 
the Y register contains its Y coordinate. 
These are passed to the routine by the 
resident integer variables X% and Y%. 

So in your own machine code 
programs you would load the X and Y 
registers with the X and Y coordinates 
of the sprite and then JSRcalcJoc. 

On exit, location &80 contains the 
low byte of the screen address and &81 
contains the high byte of the screen 
address. It’s as easy as that. 

Program VI contains the screen 
location calculator and the sprite 
routine from Program III. It demon¬ 
strates how the two routines can be 
combined to move a multi-coloured 
sprite across the screen. 

Now you’ve got two sprite routines 
I’m sure you’ll be able to conjure up 
some stunning animation. 

Next month’s article will contain a 
full listing of a multi-coloured character 
definer. Until then, happy animation. 


290 DEC674:BNE eain.part 
300 RTS 

310 .calcjoc LDAI630ISTA481 

320 LDA!l:STAIt82 

330 TYA: EORKFFs TAYi ANDI7: STA680 

340 TYA:LSRA:LSRA:LSRA:ASLAt TAY 

350 TXA s ASLAiR0L482t ASLA j RQL4B2 

360 ASLA:R0Ltt82 

370 ADC4B0jADC4C376,Y:STA176 

380 LDA482:ADC181:ADC4C375,Ys STA477 

390 RTS 

400 3NEXT 

410 FORIX’B TO 63 

420 READ LX’data 

430 NEXT 

440 YX®100 

450 FORXX*0 TO 75 

460 CALLcalc.loc 

470 CALLsprite 

480 *FX19 

490 CALLcalc.loc 

500 CALLsprite 

510 YX=YX+2*(RND(3)-2) 

520 NEXT 
530 END 

540 REH Monster data 
550 DATA63F,0,1,1,9,9,9,9 
560 DATA9,10,10,0,0,0,32,133 
570 DATA0,62A,3,6,624,624,12,4 
580 DATA8,12,12,8,8,8,8,1(22 
590 DATA0,615,3,9,418,61B,12,8 
600 DATA4,12,12,4,4,4,4,411 
610 DATA43F,0,2,2,6,6,6,6 
620 DATA6,5,5,0,0,0,610,633 



30-50 Define the sprite’s parameters. 

70-90 Enter the assembler. 

100-300 The main sprite routine - see Program Ill’s 


description. 

310-390 Screen location calculation routine. On entry X 
and Y contain the screen X and Y coordinates. In 
this example the origin is at the bottom left of the 
screen. Line 330 EORs the Y coordinate with 
&FF to change the origin from the top left corner 
to the bottom left corner. 

410-430 Read and store the sprite’s graphic data into 
page &C. 

440 Defines the sprite’s Y coordinate. 

450 Causes the sprite’s X coordinate to take all of the 
values between 0 and 75. 

460-470 Calculate the screen address for the sprite and 
then display it. 

480 Waits for the start of the retrace period. 

490-500 Delete the old sprite. 

510 Randomly changes the Y coordinate of the sprite. 

520 Next X coordinate. 

540-620 Sprite data. 

Description of Program VI 


10 REH Sprite deeo 
20 REH By Kevin Eduards 
30 data*6C00 
40 HidthM 
50 height=16 
60 HQDE 2 
70 HIHEH-62E00 
80 F0RL»8TQ2STEP2:PX s HIHEM 
90 COPTL 

100 .sprite LDAIheight:STA675:STA&7 

8 

110 LDA«ttidth:STA674 

120 LDAIdata HOD 256:STAcoluan+l 

130 LDAIdata DIV 256:STAcolu«n+2 

140 .user.entry LDXI0 

150 .eain.part LDA476iAND«6F8:STA67 

0 

160 LDA677sSTA671 
170 LDA&76:ANDI7:TAY 
180 .coluen LDA4FFFF,XsEOR(670),Y 
190 .onto.screen STA(670),Y 
200 INXiBEQ inc data hiqh 
210 .end.checks 1NY:CPX678:BEQ end. 
of.coluen 

220 CPY«8:BNE coluen 
230 LDA470iADCII7F:STA670 
240 LDA471:ADC»2:STA&71 
250 LDY40:BEQ coluen 
260 .inc.data.high INC coluan+2:JHP 
end.checks 

270 .end.of.coluen CLC:LDA676iADCI8 
:STA476:BCC no_highsINC477 
280 .no high CLC:LDA678:ADC!75:STA6 
78 
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It’s a sort of 
multicoloured 
swap shop 

THIS month we’re going to look at two more sprite routines and we’ll also see how 
useful a multicoloured character definer can be. 

Program I is the Mode 2 multi-coloured character definer as promised last 
month. This will allow you to design your own sprite graphics with minimal effort. 
These sprites can then be displayed on the screen by using the other programs 
given in this article. 

Sprites, for the uninformed, are multicoloured characters that can be freely 
moved around the screen without des¬ 
troying any background information. 


Until now the only way to design 
sprites was to use graph paper and 
coloured pens. The problem is that this 
technique is very time consuming. So to 
save time and trouble I have designed a 
simple sprite definer. Type it in, save it 
and then RUN. 

The first question you’ll be asked is 
“Load old file Y/N?” At this point your 
reply should be N - you haven’t created 
a data file yet! 

If you have saved a data file you can 
load it back in by pressing Y, after 
which the file name will be requested. 
On entering this the file is loaded and the 
editing mode is entered. 

Assuming you have not just loaded a 
file, you will be asked for the sprite’s 
dimensions. These will be provided by 
data held at the start of the file. (Skip the 
next few paragraphs if you’ve loaded a 
sprite from a file.) 

Now you will be asked for the width 
of your sprite in paired pixels - between 
1 and 8. Remember that each byte of the 
Mode 2 screen corresponds to two 
pixels. 

Predictably, the next question asks 
you for the height of the sprite - this 
time in multiples of eight pixels (the 
height of one character cell). 

The editing mode will be entered as 
soon as the sprite’s height has been 
typed in. If you’ve loaded a file from 
tape or disc, you’ll be in the editing 
mode already. 

A grid, directly corresponding to the 
size of the sprite, will be displayed on the 
screen. Underneath it is the colour 


palette which consists of 16 differently 
coloured blocks. 

Below the red block is the colour 
pointer. This indicates the colour of the 
editing pen - that is, the colour you’ll be 
filling the cells of the grid in with. 
Initially the editing pen is red. 

The pointer, and hence the colour, 
can be changed by pressing the ft) and f 1 
keys, ft) selects the colour to the left of 
the colour pointer and fl selects the 
colour to its right. 

You should have also noticed the 
cursor flashing at grid reference A,A. 
This cursor is your means of indicating 
which pixel of the sprite is being edited. 

You can move the cursor anywhere in 
the grid by pressing the appropriate 
cursor arrow key. Once you’ve 
correctly positioned the cursor you can 
change the colour of the cell to the 
selected pen colour by pressing Space. 
Doing this when the pen is black clears 
the cell, since black is the background 
colour. 

When being edited the sprite is 
magnified several times. To view the 
sprite “life-size” press f2. It will now be 
displayed to the right of the editing grid. 
The editing mode will be automatically 
resumed. 

If at any time you want to fill the 
whole grid with the palette colour you 
can do so simply by pressing f8. Be very 
careful though - your previous design 
will be erased. 

If you wish to redefine the sprite’s 
dimensions you press f7 while in the 
editing mode, which has the effect of 


Part five 

HDUITD 

WRITE 

MACHINE 

CHIDE 

GAMES 

By KEVIN 
EDWARDS 


rerunning the program. 

When you are satisfied with your 
creation you can save the sprite to tape 
or disc by pressing S. 

You will then be asked whether or not 
you wish to save just the sprite data. 
Entering N indicates to the program 
that the sprite’s dimensions should also 
be saved. This information is needed if 
the sprite is to be reloaded at another 
time for editing. 

Pressing Y saves just the sprite data. 
This means that the sprite dimensions 
are not saved and that the file cannot be 
loaded by the definer for editing. 

The data is saved in this way so that 
the sprite routines, introduced in last 
month’s article, can be used to display 
the data. In other words, the data is 
saved column by column from the left of 
the sprite to the right. 

After either selection you will be 
asked for the file name under which the 
file will be saved. This must be a 
maximum of seven characters in length 
so that the program can be used with 
disc systems. 

The final command, L, allows you to 
load a new sprite into memory. 

After pressing L the file name of the 
sprite should be entered. The sprite will 
now be loaded - make sure you’ve 
saved the previous sprite beforehand or 
you will lose it forever. 

Also remember that the file cannot be 
loaded if the sprite’s dimensions were 

-► 
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10 REM Multi-size Sprite routine 

end_checks 

420 PROCsprite onoff 

20 REM Bv Kevin Edwards 

220 .end of.colunn CLC:LDAfc76:ADC48 

430 NEXT XIX 

30 MODE 2 

:STA&76:BCC no high: INCI.77 

440 END 

40 HIMEM=62E00 

230 .no.high CLC:LDA*(78:ADC*<75:STA* t 

450 DEFPROCsprite.onoff 

50 FORL=0TO2STEP2:PX=HIMEM 

78 

460 XX=XlX:YX=255:CALLcalc_loc 

60 10PTL 

240 DEC674:BNE main part 

470 colu»n?l=0:colu«n?2=6C 

70 .sprite STX674 

250 RTS 

480 XX=4:YX=24:CALLsprite 

80 STY475:STY678 

260 .calc.loc LDA«ti30:STAIi81 

490 ENDPROC 

90 .user entry LDXI0 

270 LDA40:STAIt82 

500 DATA 0,0,0,Ml,611,0,Ml,Ml 

100 .nain’part LDA&76:AND#I/F8:STAi<7 

280 TYA: EORIttFF: TAY: AND47: STAt<80 

510 DATA 0,0,0,0,0,0,3,3 

0 

290 TYA:LSRA:LSRA:LSRA:ASLA:TAY 

520 DATA 1,1,1,1,0,0,0,0 

110 LDA677!STA671 

300 TXA:ASLA:R0L682:ASLA:R0L682 

530 DATA 8,Dll,411,633,627,127,127, 

120 LDA476:ANDI7:TAY 

310 ASLA:R0L&82 

633 

130 .colusn LDA6FFFF,X:EOR(670) ,Y 

320 ADC680:ADC6C376,Y:STA676 

540 DATA 611,611,4,4,4,4,3,62B 

140 .onto.screen STA(670),Y 

330 LDA482:ADC681:ADC4C375,Y:STA&77 

550 DATA 62B,62B,62B,62B,617,617,61 

150 INX:BEQ inc data high 

340 RTS 

7,617 

160 .end checks INY:CPXfc78:BEQ end. 

350 1NEXT 

560 DATA 0,622,622,633,61B,61B,41B, 

of coluan 

360 FOR LX=0 TO 65F 

633 

170 CPY#8:8NE colunn 

370 READ LX7&C00 

570 DATA 422,622,8,8,8,8,3,3 

180 LDA670:ADCI47F:STAIt70 

380 NEXT 

580 DATA 3,3,3,3,3,3,3,3 

190 LDA471sADCI2:STA471 

390 FOR X1X=0 TO 78 

590 DATA 0,0,0,422,622,0,622,622 

200 LDY40:BEQ colunn 

400 PROCsprite.onoff 

600 DATA 0,0,0,0,0,0,3,3 

210 .inc.data.hiqh INC colu«n+2:JMP 

410 »FX 19 

610 DATA 2,2,2,2,0,0,0,0 


Program ll 


routine all we need to do is: 

• Call the screen location calculator 
routine (.calc_loc) with the screen X 
and Y coordinates in the 6502 X and 
Y registers - line 460 of Program II. 
The result is automatically stored in 
zero page, ready for the sprite 
routine. 

• The pointer to the sprite graphic data 
must be stored into locations 
(column-f 1) and (column+2) - low 
byte then high. See line 470 of 
Program II. 

• The dimensions of the sprite should 
be loaded into the X and Y registers. 
Now the main sprite routine can be 

called (.sprite) - line 480 of Program II. 
This displays/erases the sprite on/from 
the screen. Remember, the sprite routine 
uses EOR! 

It’s still rather long winded, but 
there’s no simple way of passing so 
many parameters to the relevant 
routines. 

The effects produced by all the 
programs so far have relied on a little bit 
of Basic. The problem with this is that 
jumping in and out of Basic takes up 
valuable time. 

This is made even worse when 
sections of a Basic program are 
executed in between machine code 
routines - especially when timing is 
critical such as when using *FX 19 to 
wait for start of retrace period. 

So now we move on to Program III, 


From Page 91 

not saved when the file was originally 
created. 

Files which contain only sprite data 
are ready to be used with the sprite 
display routine without modification. 
All you need to do is *LOAD the data 
into page &C (or wherever the data is 
needed) and change the sprite para¬ 
meters in the sprite routine accordingly. 

The start of your sprite program 
should look something like this: 


10 *L0AD SPRITE1 C00 
20 widths 
30 height-16 
40 data=fcC00 

50 REM Start of sprite routine 


All this is quite simple so far. What 
we need now is a routine that will be 
capable of displaying sprites of varying 
sizes after the program has been 
assembled. 

After all, I’m sure you’ll be using 
sprites of different sizes in your own 
programs. A routine capable of 
displaying only one size of sprite is 
rather limiting. 

Ideally, what we require is a routine 
we can call with the dimensions of the 
sprite held in the 6502 X and Y 
registers. In fact, only a few changes are 
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required to last month’s sprite routine to 
do this. 

Program II is the modified sprite 
routine along with the screen location 
calculator from last month’s article. 
This is a clever routine that calculates 
the screen location, for Mode 2, of a 
specified X and Y coordinate using the 
bottom left corner as the origin. 

Program II shows how easy it is to 
move a sprite - in this case a flower pot 
- across the screen using the new 
routine. 

To display a sprite using the new 
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Line No. 


40-60 

70 

80 

90 

100-110 


120 


130-140 


150 


160 


170 


180-200 


210 


Enter assembler and 
assembles code at &2E00. 
Stores width of sprite in 

674 - in paired pixels. 
Stores height of sprite in 

675 and &78 - in pixels. 
Data offset register = 0. 
Copy column start address 
into &70, &71, the low 
byte being the top of the 
current character column 
(AND &F8). 

Loads offset register with 
screen low byte ANDed 
with 7 - to get the offset 
from the top of the 
character column. 

Read data byte, EOR it 
with screen byte and store 
it back in video RAM. 
Increments data offset 
register. If X register is 
zero, branch so that data 
pointer high byte can be 
incremented. 

Increments screen memory 
address offset register. 
Checks if end of column 
has been reached. If it has, 
the branch is taken. 
Checks to see if start of 
next character row column 
has been reached. Bran¬ 
ches if it hasn’t. 

Add &280 to screen 
address to move down to 
next character row. Then 
change screen offset regi¬ 
ster, Y, to 0. 

Increments data pointer 
high byte and continues 


with rest of the column. 

Adds eight to column’s 
start address. This moves 
start address right by two 320 
pixels. 

Changes data offset stop 
pointer so that end of next 
column will be terminated 
correctly. 

Checks to see if all of the 330 
columns have been dis¬ 
played. Branches if they 
haven’t. 

Exits from sprite routine. 

Stores Mode 2 screen start 
address high byte in &81. 

Stores 0 in the workspace. 

This is used to accom¬ 
modate any overflow that 
occurs when X is mul¬ 
tiplied by 8. 

EORs the Y coordinate 
with &FF (to change origin 
from top left corner to 
bottom left corner) and 
then ANDs result with 7. 

This tells us how many 
whole character rows down 
the screen the sprite is. 

Calculates INT(Y/8)*2. 

The result of Y/8 is 
multiplied by 2 to allow us 
to make use of ROM 
multiplication table. This 
starts at &C375 and con¬ 
sists of 32 entries of an 
&280 multiplication table. 

Each entry in table is stored 
in pairs - high byte then 
low byte. 

300-310 Calculates X*8. The three 

most significant bits of the 500-610 


220 


230 


240 


250 

260 

270 


280 


290 


340 

350 

360-380 

390 

400 

410 

420 

430 

440 

450-490 

460 


470 

480 


result are held in bits 0 to 2 
of location &82 the work¬ 
space. 

Adds screen low byte to 
low byte of result of X*8. 
Then adds low byte of 
&280 multiplication table 
to result. The final total is 
stored in location &76. 
Adds high byte of X*8 to 
screen address high byte. 
Then adds high byte of 
&280 multiplication table 
and stores result in location 
&77 - any carry which 
may have occurred from 
the addition of the low 
bytes is also included in the 
result. 

Back to Basic. 

Exits assembler. 

Read and store sprite data 
- a flower pot. 

Start of a loop - this defines 
X coordinate of sprite. 
Displays sprite on screen. 
Waits for retrace period. 
Erases sprite from screen. 
Next X coordinate. 

End of program. 

The sprite display/erase 
procedure. 

Sets X% and Y% to sprite’s 
screen coordinates and 
calls screen location 
calculator routine. 

Resets sprite data pointer. 
Defines sprite’s dimensions 
before CALLing main 
sprite routine which in turn 
displays/erases the sprite. 
Flower pot data. 


Description of Program II 


which uses only machine code to move 
the flower pot up the screen. 

The procedure PROCsprite_onoff, 
from Program II, has been replaced by a 
subroutine (.onoff) - lines 100-120. 

Location &83 is used to keep track of 
the sprite’s Y coordinate. Between each 
movement, 4 is added to Y to move the 
sprite up 4 pixels - line 90. Try changing 
line 90 so the sprite moves one pixel at a 
time. All you need to do is change the 
ADC#4 to ADC#1. 

By using simple programming tech¬ 
niques you’ll be able to produce fully 
animated sprites. This can be achieved 
by flicking between different sets of 
sprite data just like flicking through a 
book which has different sketches on 
each page. 

I’ll leave that problem for you to solve 
- it’s not as hard as it sounds. 

See you next month when we’ll look 
at some more useful techniques found in 
machine code games. 


10 REM Full aachine code deao 

160 .aain.part LDA476tANDI4FBiSTA47 

20 REN By Kevin Eduards 

0 

30 NODE 2 

170 LDA&77: STAIt71 

40 HINEH=12E00 

180 LDA476:ANDI7:TAY 

50 FORL=0TO2STEP2:PX=HIMEH 

190 .coluan LDA4FFFF,X:EOR(470),Y 

60 COPTL 

200 ,onto_5creen STA(470),Y 

70 .deao LDAt23:STA&B3 

210 INXsBEQ inc.data.high 

80 .dead JSRonoff:LDA# 19:JSR&FFF4 

220 .end.checks 1NY:CPX478:BEQ end. 

s JBRono-f f 

of.coluan 

90 LDAI<83: CLC: ADCI4: STA483: BCCdeao 

230 CPY#8:BNE coluan 

1: RTS 

240 LDA4701ADCI47F:ST A470 

100 .onoff LDX*20tLDYti83iJSRcalc_lo 

250 LDA47l:ADCI2:STA471 

c 

260 LDY40:BE6 coluan 

110 LDA*0:STAcoluan+1 1 LDAt&CiSTAcol 

270 .inc.data.high INC coluan+2sJHP 

uan+2 

end.checks 

120 LDX#4:LDYft24tJSRspriteiRTS 

280 .end.of.coluan CLC:LDA476:ADCIB 

130 .sprite STX474 

:STA4t76:BCC no.high:INC477 

140 STY475iSTY478 

-► 

150 .user.entry LDXI0 



Program III 
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Join the communication revolution 

We’ve found the 


missing link! 


By DEREK 
MEAKIN 

Managing Editor 
The Micro User 


MANY months ago we forecast that 1985 would be the Year of 
Communications. And so it is turning out. 

Sales of modems are soaring. Micro users are joining Prestel in 
their thousands. Bulletin boards are springing up all over the country. 

But until now one thing has been missing. 

What has been desperately needed was a national database for 
microcomputers that would combine a low-cost electronic mail 
service with a giant bulletin board you could access first time every 
time, that would allow you to chat freely with other users, that would 
have no restriction on the length of material you could send or 
receive - and would also enable you to send telex and telemessages 
from your own micro. 

All this, and much much more, you can do with MicroLink. For this 
one comprehensive service is the missing link in Britain’s 
communications network. 

And the carrier through which all MicroLink’s facilities are being 


offered is the most respected name of all - Telecom Gold. 

Until now Telecom Gold has been the preserve of big business - 
used by the giants of industry, commerce and finance to link their 
operations in Britain with the rest of the world. And Telecom Gold’s 
charges reflected its elevated status. 

That has now changed. Thanks to MicroLink, every micro user 
can afford to key into Telecom Gold and make use of its growing 
range of services. For less than the cost of a first class stamp you can 
have a message the size of this page delivered to one destination or 
hundreds... all in a fraction of a second. And that’s just one example 
of the time and money you’ll be able to save with MicroLink. 

All of us at The Micro User are very excited about the enthusiastic 
reception the new service has been given by our readers - and about 
its unlimited potential for future development. 

Come and join us - and explore with us the whole new world that 
is being opened up by MicroLink. 
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440 

NEXT 


450 

CALLdeio 

290 .no high CLC:LDA478:ADC475iSTA4 

460 

END 


78 

470 

DATA 

0,0,0,(11, 111, 0,till,trll 

300 DEC474:BNE lain part 

480 

DATA 

0,0,0,0,0,0, 3,3 

310 RTS 

490 

DATA 

M,l,1,0,0,0,0 

320 .calc.loc LDAI430ISTA481 

500 

DATA 

0,1(1 l,lil 1,133,427,1.27,127, 

330 LDAI0:STA482 

W3 



340 TYA t E0RI4FF : TAY s ANDI7:STA480 

510 

DATA 

411,411,4,4,4,4,3,42B 

350 TYA:LSRA:LSRA:LSRAiASLA:TAY 

520 

DATA 

42B,42B,428,42B,417,4!7,41 

360 TXA:ASLA:R0L&B2:ASLAtR0Ltc82 

7,lil7 



370 ASLA:R0L&82 

530 

DATA 

0,422,422,433,41B,41B,41B, 

380 ADC480:ADC4C376,Y:STA476 

433 



390 LDA482:ADC481:ADC!iC375,Y;STA477 

540 

DATA 

422,422,8,8,8,8,3,3 

400 RTS 

550 

DATA 

3,3,3,3,3,3,3,3 

410 1NEXT 

560 

DATA 

0,0,0,422,422,0,422,422 

420 FOR LX=0 TO lt5F 

570 

DATA 

0,0,0,0,0,0, 3,3 

430 READ LX?(tC00 

580 

DATA 

2,2,2,2,0,0,0,0 

The machine code routines in 
Program III are identical to those in 
Program 11 with the following additions. 

retrace period and then erases 
sprite. Remember the display and 
erase routines are the same. 


Line No. 

70 Stores sprite’s Y coordinate in 
location &83. 

80 Displays sprite, waits for the 


90 Adds 4 to sprite’s Y coordinate to 
move it up the screen by 4 pixels. A 
branch is taken if sprite’s Y 
coordinate hasn’t overshot top of 
screen. This repeats process for a 


HDMTD 

WRITE 

MACHINE 

CDDE 

GAMES 


new position. Otherwise program 
finishes. 

100 Calculates screen location for the 
sprite’s X and Y coordinates. 

110 Resets sprite data pointer so that 
data starting at &C00 is displayed. 

120 Defines sprite’s dimensions before 
calling sprite display/erase routine. 
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How to keep 


NEARLY all games have a score of 
some kind, and wherever there's a score 
there's a high score table. These are two 
of the subjects we'll be looking at this 
month. 

First we'll consider how to keep 
and increase a score. 

The easiest way to store the score is 
as a sequence of numeric Ascii 
characters — 0 to 9. This makes it easier 
to output, as we shall see. 

One very useful routine in the 
operating system is OSWRCH 
(&FFEE). Calling this routine will print 
the character whose Ascii code is held in 
the accumulator - just what we need to 
print out the score. 

For example, if the accumulator 
contains 65 and OSWRCH is called, the 
letter A is printed on the screen - 65 
being the Ascii code for A. You see. 
OSWRCH is the machine code 
equivalent of VDU. 

Take a look at the following example: 



This is exactly the same as VDU 
31,0,6 - move the text cursor to 
coordinate 0,6. 

OSWRCH allows you to perform 
many operations from drawing triangles 
to turning printers on and off. See page 
378 of the User Guide for a list of the 
VDU codes. 

Program I uses OSWRCH to 
position the text cursor (line 170) and 
print out the score digits (line 190). 

The score is held in eight consecutive 
locations. This means that the largest 
number that can be represented is 
99999999! The base location of the 
score is pointed to by the variable 
thescore . 

Program I contains two routines. One 
increases the score by 10 points (lines 
90-160) and the other prints the score 
on the screen (lines 170-210). 

These have been separated so that the 
add 10 subroutine can be called several 
times to make it into an add 10*n 
subroutine — n being the number of 
times the routine is called. 

In other words we can call the add 10 


(and 

raise! 

your 

score 

routine 5 times to add 50 to the score 
before we print it on the screen. 

Some games use score routines which 
print leading zeros. For example, one 
game might print the score as ‘*000150“ 
and another would print it as “ 150“. I'm 
sure that you'll agree that the latter 
looks the tidier. 

So to make the score output neat and 
tidy leading zeros will be replaced by 
spaces. This must be taken into account 
by the score routine. 

Try Program 1, pressing a key to add 
10 to the score. 

Line 230 is very important. This 
initialises the score to 0. The length of 
the string should always be eight 
characters in total with a zero at the end. 

The score is increased by incremen¬ 
ting the Ascii character in the tens 
position of the score - remember 
Hundreds Tens and Units. If the digit in 
the tens position is a nine it must be 
replaced by a zero and 1 must be added 
to the hundreds column. 

In fact the same routine which 
increased the tens is used to add one to 
the hundreds. This is achieved by 
decrementing the score offset register so 
that it points to the hundreds column 
instead of the tens column - the most 
significant digits of the score are stored 
first. 

Again, if the digit is a 9 the routine 
puts a zero in the score, decrements the 
offset register and branches back on 
itself. You’ll be able to understand this 
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better by following Program I through 
in your head. 

One of the features that has been 
added to more and more games is the 
high score table. This allows a person 
who has accumulated a good score to 
enter their name into a table of other 
scores. 

Most high score tables keep a record 
of the top ten scores. The higher the 
score the higher its position is in the 
table. 

When a new high score is recorded 
space must be provided to accom¬ 
modate the new score. This is done by- 
moving all the scores less than the new 
one down the table one place. This 
means that the lowest score must be 
lost. 

The name of the person who achieved 
the new score is requested and entered 
into the table. 

It gives players great satisfaction 
when they see their name and score 
above all of the others. It's also very 
useful when several players are having a 
competition. 

Achieving this in machine code is 
quite tricky. Several problems must be 
solved first: 

• Storing the high scores and names in 
memory . 

• Accepting the name of the person 
who achieved the high score . 

The obvious way to store the names 
and scores is in Ascii. This makes it 
easier for us to print the table — using 
OSWRCH - and to use the Ascii 
characters, corresponding to new score, 
from Program I. 

Program II is the high score table 
routine which keeps a record of the top 
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10 REM Score routine 
20 REM By Kevin Edwards 
30 MODE 7 
40 HIMEM=fc2800 
50 thescore=&2AA0 
60 FOR pass=0 TO 2 STEP 2 
70 PX=HIMEM 
80 COPT pass 
90 .add 10 LDXI6 

100 .examinedigit LDAthescore,X 
110 CMPIASC" ":BEQmake it a 1 
120 CMP#ASC“9":BNEincdigit 
130 LDA0ASC"0“sSTAthescore,X 
140 DEXiBPLexaainedigit 
150 .«ake_it_a_1 LDA0ASC*1":STAthes 
core,Xs RTS 

160 .incdigit INCthescoreJiRTS 
170 .scoreout LDA031:JSRtFFEEsLDAI1 
5: JSRIiFFEEs LDA# 12: JSR&FFEE 
180 LDY«0 

190 .nextdig LDAthescore,YsJSRtFFEE 
200 INYsCPYI8:BNEnextdig 
210 RTS 
220 3NEXT 

230 $thescore=" 0“ 

240 REPEAT 
250 CALLscoreout 
260 CALLadd 10 
270 A7.=6ET 
280 UNTIL 1=2 



40-80 

90 

100 

NO 

120 

130-140 

150 

160 

170 

180-200 

210 


Enter assembler. 

Sets score offset register to 6. 

Reads digit. 

checks if it's a space. If it is make it a one. Spaces 
arc used instead of leading zeros. 

Is the digit a 9? Branch if it isn't. 

If it's a space make it a zero and repeat the 
process for the next digit along. 

Makes the score digit 1. 

Increments the score digit by one to add 10 to the 
score and then exit. 

Positions the text cursor - VDU 31,15.12. 
Output the score digits. 

Exits the routine. 


Description of Program I 


Program I 


nine scores. Run it and enter your name. 

Line 860 specifies the new score. Try 
changing it. but make sure that the score 
string is eight characters in total. 

The high score routine execution 
address is pointed to by the variable 
start. Make sure you've set the score up 
in memory before you call the routine - 
the score address is given by the variable 
newscore. 

The names of the high scores are 
stored sequentially in nine groups of 16 
characters. Only 15 characters of each 
hold the name, the other holds 
CHR$(13) - carriage return. The 
variable names points to the first name. 

The scores are stored sequentially in 
nine groups of eight characters. The first 
character in each group is the most 
significant digit of the score. 

The names and scores were limited to 
16 and eight characters to simplify 
calculations needed to locate a specific 
score by multiplication. For example, 
the start of the text for the third score 
can be found by multiplying 8 (number 


of characters per score) by the 
position. I, the result being 16 
(8*(3-l)). 

A number can be multiplied by 8 by 
shifting it left three times using the 
command ASL - see line 220. Shifting it 
left once more, again using ASL. is the 
same as multiplying the original number 
by 16 - see line 230. 

Of course this only works if the 
original number is less than 16 - which 
it will be in our case. If it is greater or 
equal to 16 the result will overflow 
because the maximum number that a 
register or location can hold is 255. 

The second problem was how to 
accept an input from the user when his 
name is requested for the high score 
table. This is a lot easier than it sounds. 
Another operating system call allows us 
to do this. 

The call required is to OSWORD 
(&FFF1) with the accumulator set to 0 
- OSWORD 0 for short. The X and Y 
registers hold the low and high byte, 
respectively, of a control block which 


gives further information about the 
operation to be performed. 

For example, if the control block is at 
location &A60 the following routine 
would execute OSWORD 0 correctly. 


LDXU60 
LDYf&A 
LDAI0 
JSR ScFFF 1 

But before this can be executed the 
control block must be set up. This 
specifies the following information: 

• The address in memory where the 
input string is to be stored - low byte 
then high byte. 

• The maximum number of characters 
to be accepted. 

• The minimum acceptable Ascii 
character. 

• The maximum acceptable Ascii 
character. 

For example, we'll set up the control 

-► 
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10 REM Hi ah Score Table 
20 REM By Kevin Edwards 
30 MODE 7 
40 HlMEM*(t2800 
50 names s k2A00 

60 newscore=&2AA0!work5pace«ii2AB0 
70 scores=&2B00 
80 FOR pass*0 TO 2 STEP 2 
90 PX=HIMEM 
100 COPT pass 

110 .start LDAI22:JSR&FFEE: LDAI7:JS 
RfcFFEE 

120 LDXt0:TXA:PHA 

130 .checkanother ASIA:ASIA:ASIA:TA 
X:LDY40 

140 .chart LDAnewscore,Y!CMPscores, 
X:BCCnotgreater:BNEinsert 
150 INX: 1NY!CPY4I8!BCCchar 1 
160 BCSinsert 

170 .notgreater PLA:TAX:INX:TXA:PHA 
:CPXI9:BCCcheckanother 
180 LDA#255iSTAworkspace+2:JMPFinis 
h 

190 .insert LDYI0 

200 .messageout LDA*essage,Y:BEQexi 
hJSR&FFEE: INY: BNEaessaqeout 
210 .exit PLAsPHA:STAworkapace+2 
220 ASLA:ASLA:ASLAsSTAworkspace 
230 ASLA:STAworkspace+l 
240 CMPI128:BEBaovenewscore 
250 LDXH127 

260 .copynames LDAna»es,X:STAnaaes+ 
16, X:DEXtCPXworkspace+1:BNEcopynames 
270 LDAnames,Xs STAna»es+16,X 
280 LDXI63 

290 .copyscores LDAscores,XtSTAscor 
es+8, X:DEX:CPXworkspace:BNEcopyscores 
300 LDAscores,X:STAscores+8,X 
310 .movenewscore LDXworkspacesLDY* 

0 

320 .copynewscore LDAnewscore,Y:STA 
scores,X:1NX:INY:CPY»8:BCCcopynewscor 
e 

330 .deleteoldname LDXworkspace+liL 


Program II 

From Page 145 

block at location &A60 with the 
following information: 

Input bufTcr address = &920 
Line length = &20 (32 characters) 
Minimum Ascii = &20 (32 decimal) 
Maximum Ascii = &7E (126 decimal) 

Therefore the corresponding control 
block svould be: 

&A60 = &20 
&A61 = &9 
&A62 = &20 
&A63 = &20 
&A64 = &7E 


DY#15:LDA«32 

340 .delete STAna«es,X:INX:DEYsBPLd 
elete 

350 LDAworkspace+1:STAoswordblock:L 
DAM0:LDXftoswordb1ock MOD 256:LDYtoswo 
rdblock DIV 256:JSR6FFFl 
360 .Finish PLA:JSRdisplay 
370 LDYI0 

380 ,#essageout2 LDA#essage2,Y:BEBe 
x i t2: JSRSiFFEE: INY: BNE«essageout2 
390 ,exit2 JSRfeFFE0:LDAi&7E:JMPfeFFF 
4 

400 .display LDAI12:JSR(tFFEE 

410 .displayscores LDXI0 

420 .nextscore LDAI31:JSRttFFEE:LDA# 

11 JSRiFFEEt TXA:ASLAt ADCI3:JSR&FFEE 
430 TXAt AND*7!CMPII71 BNEcolourok: LDA 

12 

440 .colourok CLC:ADC*129:JSR6FFEE 
450 LDA432:CPXworkspace+2:BNEpositi 
on:LDA#136 

460 .position JSRiFFEE 
470 TXA:CLC:ADCH49:JSRfcFFEE 
480 LDY43:JSRdots 

490 TXA:PHA:ASIA:ASIA:ASLA:TAX:LDYI 
7 

500 .nextdigit LDAscores,XsJSRlcFFEE 
: INX:DEY:BPLnextdigit 
510 LDY44:JSRdots 
520 PLA:PHA 

530 ASLA:ASLA:ASLA:ASLA:TAX:LDYH15 
540 .nextletter LDAnames,X:CMP#13:B 
EQski p j OSRtcFFEE: INX: DEY: BPLnext letter 
550 .skip PLA:TAX 
560 INX:CPX#9:BCCnextscore 
570 RTS 

580 .dots LDAi46:.dotl JSRItFFEE:DEY 
:BPLdotl:RTS 

590 .oswordblock OPT FNequb(0) 

600 OPT FNequb(names DIV 256) 

610 OPT FNequb(15) 

620 OPT FNequb (1:20) 

630 OPT FNequb(67E) 

640 .message OPT FNequb(31) 


At this point the OSWORD routine 
can be called. 

The micro will now accept an input. 
Pressing Return or Escape will 
terminate the routine. Ctrl+U will delete 
the whole line. Delete will erase the 
previous character and Copy will copy 
the character at the editing cursor. On 
exit the carry flag will be 1 if Escape 
terminated the input. 

Any attempt to enter more characters 
than specified in the control block will 
result in a beep - VDU 7. 

Characters which are outside the 
Ascii range are printed but not entered 
into the string buffer. 


650 OPT FNequb(3) 

660 OPT FNequb(9) 

670 OPT FNequb(133) 

680 OPT FNequsCYou're score is in 
the top nine") 

690 OPT FNequb(31) 

700 OPT FNequb(7) 

710 OPT FNequb(11) 

720 OPT FNequbl134) 

730 OPT FNequsCPlease enter your n 
ame“) 

740 OPT FNequb(31) 

750 OPT FNequb(11) 

760 OPT FNequb(13) 

770 OPT FNequb(130) 

780 OPT FNequb(0) 

790 ,message2 OPT FNequb(31) 

800 OPT FNequb(6) 

810 OPT FNequb(23) 

820 OPT FNequb(133) 

830 OPT FNequsCPress a key to cont 
inue") 

840 OPT FNequb(0) 

850 1NEXT 

860 tnewscore=" 4560“ 

870 $scores=" 9000 8000 70 

00 6000 5000 4000 3000 

2000 1000 " 

880 *names="HISSING SID “+"FRED 
DY FLUKE "+“KEYB0ARD BASHER "+"SQU 
IDGY BOD “+“K0N6 BASHER “+“TR 
ICKY DICKY "+-SPARR0W MAN "+"H 
AVE A NICE DAY "+“DENIM DENNY 
890 CALL start 
900 END 

910 DEFFNequb(byte) 

920 ?PX=byte 
930 P’/.=PX+1 
940 =pass 

950 DEFFNequs(string#) 

960 IPX=string$ 

970 PX=PX+LEN($PX) 

980 =pass 


For those of you who are interested. 
Basic uses OSWORD 0 for its INPUT 
statements. 

Another input routine, used in line 
390. is OSR DC 11 (&FFEO). This waits 
until a key is pressed and returns the 
key's Ascii value in the accumulator — 
just like Basic’s GET command. 

If Escape is pressed the accumulator 
will contain &1B. This must be 
acknowledged by issuing OSBYTE 
&7E (126) - also on line 390. 

• Then's il for this month. Next 
month we'll look at random numbers 
and other useful techniques used in 
machine code games. 
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50-70 Define work space area for the high scores. 

80-100 Enter assembler. 

110 Changes to Mode 7 - VDU 22,7. 

120-180 Check if the new score is greater or equal to the 
other high scores. 

190-200 Print out a message indicating that the new score 
is in the top 9. 

210 Retrieves the position in the table where the new 
score is to be inserted. 

220 Multiplies the position by 8 to get the offset for 
the corresponding score. 

230 Multiplies again by 2 to get the offset for the 
corresponding name. 

240 If the new score is at the bottom of the high score 
table skip the insert routine - it’s not necessary. 

250-300 Move all of the names and scores down one place 
in the table. 

310-320 Copy the new score into the score table. 

330-340 Clear the existing name from the table. 

350 Accepts a name for the new score. 

360 Calls the subroutine which displays the high 
score table. 

370-380 Output the message “Press a key to continue”. 

390 Calls the read character routine and clears the 
Escape condition. 

400-570 High score display routine. 

400 Clears the screen - VDU 12. 

410 Loads the X register with 0 - this is used to keep 

count of the score being displayed. 


420 Positions the cursor - VDU31,l,Y*3+2, where 

Y is the position in the table of the score. 
430-440 Output a colour control character. 

450-460 Output a flashing control character if the score 
being displayed is the new score. 

470 Prints the position of the score 1,2..9. 

480 Prints four dots. 

490 Finds the offset of the score’s start position and 
places it in X. 

500 Prints the score. 

510 Prints five dots. 

520-530 Find the offset of the name’s start position and 
place it in X. 

540 Prints the names out. 

550-560 Test if all nine scores have been displayed. 

570 Exit routine. 

580 Prints out dots. The number is determined by the 

Y register. 

590-630 OSWORD 0 control block. 

640-780 Text for new high score message. 

790-840 Text for “Press a key to continue”. 

850 Exits assembler. 

860 Places “ 4560” into the “newscore” workspace 

- the spaces are very important. 

870 Sets up the high scores. 

880 Sets up the high score names. 

890 Calls the routine. 

900 Exits program. 

910-940 Macro for Equate byte (EQUB). 

950-980 Macro for Equate string (EQUS). 


Description of Program II 



Are YOU a first rate 
PROGRAMMER? 

Then join the Professionals! 


SYSTEMS 


DIRECT TO YOU AT WHOLESALE PRICES 


COMPUTERS 


MONITORS 


BBC B Plus 

£489 

Microvitec 1431 . 

£185 

BBC-B 

£329 

Microvitec 1451 . 

£279 

BBC-BD . 

£419 

Philips BM7502 . 

. £83 

OFS (Acorn) . 

... £90 



Z80 2nd Processor . 

£389 

DISKS 


6502 2nd Processor . 

£189 

D/SD/D80T . £20 (box of 10) 

CBM 64 . Available for 

(Fully guaranteed) 


Sinclair . 

export 

box of 10 


PRINTERS 


MODEMS 


Canon PW1080A . 

£279 

Pace Nightingale . 

£130 

Canon PW1156A . 

£389 



Kaga KP810 . 

£279 

DISK DRIVES 


Epson RX80F/T . 

£232 

Cumana CSX 100 SS 40T . 

£103 

Quendata 20cps . 

£239 

Cumana CSX400 DS 40/80T ... 

£155 

Juki 6100 . 

£332 

CumanaCD200 SS40T + PSU ... 

£242 



Cumana CD800 DS 40/80T -r PSU 

£356 

FIRMWARE 


PSU . 

.. £20 

View . 

.. £48 



Wordwise + . 

.. £48 

• Price includes VAT at 15% and delivery is 

Disc Doctor . 

.. £29 

FREE in the UK. 


Printmaster . 

.. £29 

• To order just send a cheque or postal order 



to us and the goods reach you fast. 


DATA RECORDERS 


• Trade enquiries welcome. 


Omega . 

. £21 

• Remember, our name is our guarantee. 




MACOB SYSTEMS 

8 Lister Gardens, London N181 HZ. Tel: 01 -8031622 
Telex: 8954029 att.MACOB 


Award-winning Database Software needs 
more programmers, both for freelance work 
and permanent positions. 

Applicants must be fluent in both Basic 
and machine code on at least one of the 
popular micros, and preferably have 
experience of others. 

Experience in the software industry is not 
essential, but obviously candidates must 
have written good quality software in the 
past and samples will be required. 

Pay is negotiable, depending on age, 
experience and qualifications. There are 
excellent prospects for hard working, skilful 
programmers. 

Please send SAE, C V and an example of your 
work which will be returned uncopied 
to: 

Peter Davidson, Software Manager, Database Software, 
Europa House, 68 Chester Road, Hazel Grove, 
Stockport SK7 5NY. 
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RANDOM 

THOUGHTS 

and 

KEYBOARD 

CAPERS 


IN this, the final part of the series, we 
shall be looking at random numbers and 
routines to check the keyboard. Well 
start off with random numbers. 

There are very few games which don't 
use random numbers. So for this reason 
we shall see how random numbers can 
be created using several different 
methods. 

In BBC Basic, random numbers are 
created by applying a complex 
algorithm on a series of numbers, 
known as the random seed. This causes 
pseudo random numbers to be set up in 
the seed. These seem to have no set 
pattern and so are considered random. 
In fact, they follow a series which is very 
complex. 

The complexity is such that the series 
repeats only after several million calls! 

BBC Basic’s random number gen¬ 
erator is seeded with the same number 
each time the micro is turned on. This 
results in the same random numbers 
being generated. If you don’t believe me, 
turn your micro off, then on, and run the 
following program: 


10 FOR L=i TO 10 
20 PRINT RND(10) 
30 NEXT 


Repeating the process will result in 
the same numbers being generated. 

The only way to stop the numbers 
repeating is to initialise the seed with a 
different value. 


The seed used by Basic can be found 
in zero page locations &D to &11. One 
obvious way to change the seed is to 
poke new values into these locations. 

The problem with poking values into 
the seed is that these new numbers must 
be random else another series of 
numbers will be repeated. 

We now need random numbers to 
seed the random number generator. We 
seem to be going backwards don't we? 
In fact, we can seed the random number 
generator by issuing an RND command 
with a negative parameter. 

This is favoured to the naughty 
poking method. So a command such as: 

du««y=RND(-TIME) 

at the start of the program would 
provide a solution. 

Notice that TIME was used to reset 
the seed. This is quite acceptable 
because its value will almost certainly be 
different each time it is executed since 
TIME is always changing. This results 
in an almost perfectly randomised seed. 

Implementing this in machine code is 
quite a tricky business. Before we do 
this, let’s see how BBC Basic creates a 
new set of values in the seed by 
disassembling the Basic ROM. 

The start address of the routine is 
&AF87 for Basic II micros or &AFB6 
for Basic I. If you don’t have access to a 
disassembler, printed above is the ROM 
routine which is, of course,the copyright 
of Acorn. 



GAMES 

By KEVIN 
EDWARDS 



Calling start creates five random 
bytes in locations &D to & 11 — the seed 
workspace. (Assuming the locations 
have been seeded with a value not equal 
to zero.) 

The routine looks simple but is in fact 
quite complex. See if you can work out 
what happens to the seed bytes. 

Program I is a fast, crude random 
number routine which repeatedly cre¬ 
ates a single random number and prints 
it out. Press Ctrl N before running the 
program to turn on the paging mode. 

The routine creates a random byte by 
accessing several very useful locations. 
These are: 

&FE44 - Timer 1 low order counter in 
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10 REM Random number generator 
20 REM By Kevin Eduards 
30 seed=&70 

40 FOR pass=0 TO 2 STEP 2 
50 PX=S<C00 
40 [OPT pass 
70 .random LDY«4 
80 .again 

90 LDAseed,Y:ADCseed+2:EORseed+1 
100 LDX#4 
110 .again2 

120 ROLseed+2:EORseed,X:SBCseed,Y 

130 SBCseed,X:ASLA:RORseed,X 

140 OEX:BPLagain2 

150 DEY:BNEagain 

160 LDX44 

170 .nextseed 

180 LDAseed,X:JSRprintbyte 
190 LDAIASC" " 

200 JSR&FFEE:JSR&FFEE:JSR&FFEE 

Program II 


unpredictable - depending upon the 
section of program being executed when 
the interrupt is requested. 

&FE65 - Timer I high order counter in 
the user VIA. Again, this decrements 
quickly but obviously at a slower rate 
than the low order counter - I/256th of 
the speed. 

Reading from &FE44 and EORing 
with the other two locations results in a 
random number. This method is very 
crude and probably has a poor 
frequency distribution, but it isn't half 
fast! 

A word of warning. The VIA 
registers cannot be directly accessed if 
the program is being executed in the 
6502 2nd processor memory. 

Also included in Program I is a hex 
number print routine. This prints the 
contents of the accumulator as a 2 digit 
hex number. You'll find this routine very 
useful if you haven't already written a 
similar one. 

For cases where a “better" random 
number generator is needed. Program II 
should be used. Although it's relatively 
slow, it provides five random bytes. 

The algorithm Program II uses is 
similar to the one in the Basic ROM but 
uses a slightly different approach. 

Line 360 in Program II is used to 
initialise the seed bytes. As you can see. 
it uses a low order counter in the user 
VIA as a seeding value. 

The best way to generate a true 
random set of numbers is to use the 
random routine from Program I to 
initialise the seed for Program II, then 
Program IPs random number generator 
can be used to create the random bytes. 


210 DEX:BPLnextseed 
220 RTS 

230 .printbyte 
240 PHA 

250 LSRAsLSRA:LSRA:LSRA 

260 JSRdigitout 

270 PLAiANDifcF 

280 .digitout 

290 CMP#10;BCCnumeric 

300 ADCI6 

310 .numeric 

320 ADC#48 

330 JMP&FFEE 

340 3NEXT 

350 FQRL7.=0TO4 

360 LZ?seed=?iFE44 

370 NEXT 

380 REPEAT 

390 CALLrandom 

400 UNTIL 1=2 


The end result will be a reliable set of 
random values. 

For the majority of cases random 
bytes in the range 0-255 are quite 
acceptable. But there are times when 
custom random number routines are 
needed. 

For example, in a dice game we 
require random numbers between 1 and 
6. Obviously a random number between 
0 and 255 is of no use in this case. 

Unfortunately there is no simple 
answer to this problem. The only easy 
way to do this is by using floating point 
numbers. 

Let me explain. 

A random integer between 1 and n 
can be created by using the following 
statement: 

rand=INT(RND(l)*n)+l 

Which is usually shortened to: 
rand=RND(n) 

The RND(l) returns a number 
between 0 and 0.999999999 and the n 
enlarges this number so that it falls 
within the range we require. The integer 
part of the result is taken and 1 is added 
to it to give us our final answer. 

Doing all this in machine code is quite 
a task. First of all a random number 
between 0 and 0.999999999 must be 
created (not too difficult). This is then 
multiplied by n (don't forget, we're in 
machine code). After which the integer 
part of the result is taken and I is added 
to give us our final answer. 

Let me warn you now, machine code 
floating point routines are not easy to 
write. We could of course use the Basic 
ROM routines, but that's cheating! 

You'll find that the Basic ROM 
contains some clever, and very useful 
routines which are needed at some stage 
by all machine code programmers. 

It is at this point that praise should be 
given to the author of BBC Basic. Roger 
Wilson (and all others concerned). By 
using very clever programming skills he 
provided us with one of the fastest, 
comprehensive versions of Basic avail¬ 
able for any home micro. And to add the 
icing to the cake, he included a superb 
assembler. 

That's enough of random numbers. 
Next we'll see how to check the 
keyboard. 

Checking if a key is pressed is quite a 
simple process - all we do is call a 
routine in the operating system - 
OSBYTE (&FFF4). 

Before this can be done the A, X and 
Y registers must be set up with various 
information. 

The accumulator should contain &81 
indicating that OSBYTE call &81 (read 


10 REM Crude random number 
20 REM generator 
30 REM By Kevin Edwards 
40 FOR pass=0 TO 2 STEP 2 
50 P7.=iC00 
60 COPT pass 
70 .start 

80 LDA&FE44:E0R&FC:E0R&FE65 
90 JSRprintbyte 
100 LDAIASC" rt 
110 JSRScFFEE:JSR&FFEE 
120 JMPstart 
130 .printbyte 
140 PHA 

150 LSRA:LSRA:LSRA:LSRA 

160 JSRdigitout 

170 PLAiANDIicF 

180 .digitout 

190 CMP#10:BCCnumeric 

200 ADCI6 

210 .numeric 

220 ADCI48 

230 JMPiFFEE 

240 3NEXT 

250 CALLstart 

Program / 

Front Page 81 

the system VIA (Versatile Interface 
Adapter). This counter is decremented 
every millionth of a second and so 
provides a reasonably random number. 

&FC - Accumulator copy from the 
last interrupt. Each time an interrupt 
occurs the accummulator is saved in 
location &FC. Since interrupts can 
occur at almost any time the 
accumulator's value will be almost 
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a key) is being executed. 

The X register indicates the key being 
checked. Its value should correspond to 
the key's negative key number. These 
can be found on page 275 of the User 
Guide. 

Once the negative value is known it 
must be converted into a 2's 
complement byte. This is done by 
printing the hexadecimal value of the 
number. For example, to find the value 
for X when we wish to check for the 
Spacebar we would enter: 

PRINT *-99 
which would give: 

FFFFFF9D 

The only part of the number we're 
interested in is the 9D - not the six 
leading Fs. So to check for Space we 
load the X register with &9D. 

The Y register must always contain 
&FF. 

Our key read routine would look 
something like this: 


,check_key 

LDA (IcSl 


LDX IMD 


LDY ffcFF 


JSR 4FFF4 


On exit the X and Y register will 
contain &FF if the key is pressed. If Y is 
0, the key isn't pressed. Adding this 
information to the routine would result 
in: 


.check_key 

LDA 1181 


LDX H9D 


LDY (IFF 


JSR LFFF4 


CPY ILFF 


BNE not_pressed 


JSR reaction 

.not_pressed 

(Rest of program) 


To save repeating code a general 
keyboard routine can be used. For this 
routine only the X register is required: 


. check^key 

LDA 

1181 


LDY 

(IFF 


JSR 

LFFF4 


CPY 

ILFF 


RTS 


On exit the Z 

flag 

is 1 if the key is 


pressed or 0 if it isn't. This can be 
checked for using BEQ or BNE in the 


following way: 


.check_space 

LDX IL9D 

JSR check_key 

BNE check_return 

JSR reactionl 

.check_return 

LDX *m 

JSR check_key 

BNE check_space 

JSR reaction2 

JMP check_space 

.reaction! 

(routine if space 
is pressed) 

RTS 

.reaction2 

(routine if return 
is pressed) 

RTS 


And that concludes the series. I hope 
you’ve enjoyed following it as much as 
I've enjoyed writing it. 

Over the past few months we've 
covered only a fraction of the things 
associated with machine code games. 

I hope you'll remember me when 
you're earning thousands of pounds for 
your latest machine code game. See you 
again some time. 


MAXIM 

ANEW 
16K EPROM 


• Write in machine code or in program form. 

• Assembles either from disc or directly from keyboard into memory. 
Only disc assembly requires two passes. Both methods can produce 
machine code or program format. 

• Instructions and labels in program form may be deleted, added to. 
inserted or altered. JMP tables are specially maintained. 

• Conversion from program to machine code takes typically 2 seconds 
for 16k of code. Subsequently only limited alterations may be made. 

• Optional RUN time filing system automatically saves the two most 
recent copies of the program. 

• Display always shows eighteen lines with the operational line just 
over half way down the screen. 

• Display moves forwards or backwards. Maxim calculates the correct 
starting address. 

• Labels may be used and saved with or without a program. 

• Program and labels are displayed in ASCII assembler form with 
addresses. If needed, programmes may be *SPOOLed into ASCII files 
suitable for immediate disc assembly. 

• Comprehensive set of debugging utilities. Maxim may be made fully 
transparent for single stepping both ROM and RAM. There is a second 
screen (all graphics modes). BASIC II can be freely used from within 
Maxim. 

• Maxim works at C000 on the 6502 Second Processor, leaving the 
‘language’ area free from 8000 BFFF. It is transparent for writing 
programs intended to be eprommed. 

Maxim Computer Systems Ltd. 

17 Wigmore Street, London W1 


The friendliest assembly system 
in the business — makes assembler 
almost as easy as BAS IC! 


Tired of the hours wasted peering cross-eyed at 
endless addresses, trying to remember what they 
mean? 

Maxim displays the program just as you wrote it. 
Makes debugging a pleasure — while it lasts! 

AIMD you can write programs straight 
into memory — complete with labels! 


£65 + VAT 


(includes p&p) 


Programming Screen 


FC A X Y SP NVBOI7.C STACK I 

0000 00 00 00 FT 0000000 00 00 00 CO 

0000 00 00 00 FF 0000000 00 00 00 00 


. IOVF5P 


4C5I) 

BIT SPILI/-1 

4C60 

BPL GOODMATCH 

4C62 

JMP (STARTVFXT) 

.OOOnMATCH 

4C65 

LDY INDEX 

4C68 

LDX IOC 

.NEWSTORE 

4C6A 

UA (STOPFTFD), Y 

4C61) 

STA SPILL,X 

4C70 

DFX 

4C71 

DEY 

4C72 

BPL ntmsturf: 

.INIAN 

MP 4C74 

JSR TTJBEFTNO 

4C77 

RFQ HIRAM 

4C79 

UYA »>KCX7mKK 

4C7B 

STA KBRKVHC 


>JSR TUHKFTND 


Debugging Screen 


PC A X Y SP NVBDIZC STACK 

4C74 00 FT 00 FT 1010001 02 45 00 00 

4500 00 FF' 00 FF 1010000 00 00 00 00 


. IOVFSP 

4C5D BIT SPILLr-1 

4C60 BPL OOOCMATVJI 

4C63 JMP (STAKTVFX:> 

.GOODMATCH 
4C65 LDY INDEX 

4C68 U3X »0C 

. NFWSTDRE 

4C6A U>\ (STOFFEFD) ,Y 

4C6D STA SPILL,X 

4C70 DEX 

4C71 DEY 

4C72 BPL NFWSTORK 
. INIAN’ 

MP 4C74 JSH TVBEFIND 

4C77 BFQ HIRAM 

4C79 U1A 121 

4C9B STA RBRKVBC 


>9C INIAN 
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THERE’s been such a tremendous response to my machine code games series that 
the editor’s decided that this month I’ve to give you a complete game combining 
several routines from the series. This, I hope, will help you understand how a 
machine code game should be written. 

The game uses two sprites, a character we’ll refer to as a ball, and an arrow. Your 
aim is to fire the arrow at the right moment so that it collides with the moving ball - 
it couldn’t be simpler. 

The ball drops down the screen from a random column position at different 
speeds. The arrow is controlled by you and can only be fired across the screen from 
left to right - by pressing the Spacebar. It’s not exactly Elite, but at least I can 
explain how it works. The program uses two main subroutines which are both 
related to sprites. 

The first routine sprite is responsible 
for displaying and erasing sprites - see 
Page 92 of the June, 1985, issue of The 
Micro User for a thorough description. 

The other routine calc-loc calculates 
the screen location for a screen X and Y 
coordinate - the origin of which is the 
bottom left corner. This was first used 
on Page 93 of the May, 1985, issue of 
The Micro User. 

There are several other subroutines 
which are responsible for simple tasks 
such as setting up information for the 
sprite routines and generating random 
numbers. 

The object code created by the 
program is assembled at location 
&2E00 and occupies around 400 bytes 
of memory. The game can be executed, 
once assembled, by entering: 


MACHINE 

CDDE 

GAMES 

By KEVIN 
EDWARDS 


Now let’s put 
it all together 


CALL start 

An arrow will appear at the bottom 
left of the screen. You must now wait for 
the ball - a large circle with legs and an 


ugly face - to appear in the top half of 
the screen. And at the right moment you 
should fire the arrow, by pressing Space, 
so as to cause a collision. 

Here’s an outline of the steps we 
follow to achieve this: 

1. Initialise various variables and reset 
the sprites. 

2. Wait for a random length of time and 
then put the ball on the screen. 

3. Move the ball a small distance down 
the screen. 

4. If the arrow is in motion move it right 
by one place. Otherwise, check if the 
spacebar is pressed. If it is, move the 


arrow. 

5. Check if the two sprites have 
collided. If they have, make a beep and 
jump to step 1. 

6. Check if either sprite has reached 
the edge of the screen. If this is the case 
jump to step 1, otherwise, jump to step 
3. 

As you can see, it’s quite simple. Let’s 
take a look at how the program achieves 
this. 

All this may seem a long-winded way to 
perform such a simple task, but you’ll 


10-120 Initialise various variables and select the 
assembler options. 

130-310 The sprite routine. This is responsible for 
displaying/erasing sprite characters on/from 
the screen. 

320-400 Calculate the screen location for a given X,Y 
screen coordinate. The origin is taken to be 
at the bottom left of the screen. 

420 Resets the arrow’s status. If the location 
moveflag contains zero the arrow is 
stationary, otherwise, the arrow is moving. 

430-440 Randomly select either 2 or 3 and store it in 
location speed . This indicates the number of 
pixels by which the ball will move down the 
screen. A large value would make the ball 
move faster than a smaller one. 

450-460 Initialise the arrow's screen coordinates to 
the bottom left of the screen. 

470 Displays the arrow on the screen. 

480 Places a random nybble, a four bit number 
between 0 and 15, into the X register. 

490-530 Wait for a random length of time. The length 
is determined by the random number 
returned from line 480. The delay is achieved 
by having three nested loops. This can take a 
long time to execute even in machine code. 
The random number previously created is 
used for the outer loop. 


540-550 


560 


570 

590 


600 

610 


620 

630 

640 


650 

660-670 


Calculate a random X coordinate between 
30 and 60 - in steps of 2 - for the ball. 
Giving the ball a random start address 
makes it more difficult to play the game. 
Resets the ball's Y coordinate to 200 - in the 
top half of the screen. 

Displays the ball on the screen. 

Checks if the arrow is moving. If it is then 
branch. This is done to avoid the key check 
routine which isn’t needed because the arrow 
is already moving. 

Tests to see if the Spacebar is pressed. 
Branch if false. 

Stores &FF in the arrow movement flag. 
This indicates that the arrow is now in 
motion. 

Erases the arrow from the screen. 

Increments the arrow’s X coordinate to 
move it right one place. 

Checks if the arrow has reached the 
right-hand edge of the screen and branches if 
false. 

Removes the ball from the screen then jumps 
back to the start of the main loop. 

Test for a collision between the two sprites. 
This is done by peeking the screen memory 
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10 REH Siiple deio gate 
20 REH By Kevin Edwards 
30 HODE 2 
40 $width=&74 

50 5height«U5:sheight2 s fc78 
60 coltoplow*&76:screenlow=fc78 
70 coltophigh=fc77:screenhigh=&71 
80 teip0=&80:teipl=fc81 
90 teip2 s fi(82 
100 HIHEM*&2E00 

110 FORpass=0TO2STEP2sPX=HIHEH 
120 COPTpass 
130 .sprite STXswidth 
140 STYsheightiSTYsheight2 
150 .user..entry IDXI0 
160 .aainjart LDAcoltoplow:AND4&F8 
sSTAscreenloN 

170 LDAcoltophighrSTAscreenhigh 
180 LDAcoltoploH:AND#7:TAY 
190 .coluin LDAfcFFFF,X:E0R(screenlo 
m) V Y 

200 .ontojcreen STA(screenlow),Y 
210 INXiBEQ incjJata.high 
220 .ind.chtcks INY:CPXsheight2sBEQ 
endj)f .coluin 
230 CPY#8:BNEcoluin 
240 LDAscreenlow:ADCH7FjSTA5creenl 

ON 

250 LDAscreenhigh:ADC42:STAscreenhi 
gh 


260 LDY#0:BEQ coluin 
270 .inc.datajdgh INCcoluin+2sJNPe 
nd.checks 

280 .end.of.coluin CLC: LDAcol tool ow 
:ADC#8:STAcoltoploM:BCCno.high:INCcol 
tophigh 

290 .no.high CLC:LDAsheight2:ADCshe 
ight:STAsheight2 
300 DECsNidth:BNEiain.part 
310 RTS 

320 .calcJoe LDA#&30:STAteapl 
330 LDAI0:STAteip2 
340 TYAsEORWFF:TAY:ANDI7:STAteip0 
350 TYAsLSRA:LSRAiLSRAsASLAsTAY 
360 TXA:ASLA:R0Lteap2:ASLA:R0Lteap2 
370 ASLA:R0Lte«p2 

380 ADCteip0tADCU376,Y:STAcoltopio 

M 

390 LDAteip2iADCteip1:ADC&C375,Y:ST 
Acoltophigh 
400 RTS 
410 .start 

420 LDAI0:STAiovef1ag 
430 JSRrandoibyte:AND*1 
440 CLC:ADC#2:STAspeed 
450 LDAI0:STAarrowX 
460 LDA#30:STAarronY 
470 JSRarrowonscreen 
480 JSRrandnyb 
490 LDYI0 


500 .delayl 

510 DECteip0:BNEdelay1 
520 DEYsBNEdelayl 
530 DEXsBPLdelayl 
540 JSRrandoibyte:AND«&F:ASLA 
550 CLC:ADC130:STAbal1X 
560 LDA#200:STAbal1Y 
570 JSRballonscreen 
580 .repeat 1 

590 BITioveflag:BMIioveacross 
600 LDX#&9D:JSRinkey:BNEnotspace 
610 LDAI&FFiSTAioveflag 
620 .loveacross JSRarrowonscreen 
630 INCarrowX 

640 LDAarrowXsCHPI70:BNEreplacearro 

w 

650 .eraseball JSRballonscreen:JMPs 
tart 

660 .replacearrow LDXarrowXsLDYarro 
wYsJSRcalc.ioc 

670 LDYIM0;LDA(coltoplow),Y:BEQnoh 
it 

680 LDA#7:JSR&FFEE 

690 JSRballonscreen:JKPstart 

780 .nohit JSRarrowonscreen 

710 .notspace LDAtl9:JSR&FFF4 

720 JSRballonscreen 

730 LDAbal1Y:SEC:SBCspeed:STAbal1Y 

740 CMPV10:BCSreplacebal1 

750 JSRarrowonscreen:JMPstart 


From Page 83 

find this is the case for most machine 
code games. 

When writing your own games you 
should break the program into simple 
steps - as I’ve done at the start of the 
article. This will make the programming. 


easier and allow you to identify sections 
of repeated code which can be put into a 
subroutine - thus saving you memory. 

I hope this has given you some more 
ideas for writing your own games. For 
starters, try modifying the one described 
here. For instance, you might have two 
arrows, one low, the other high. Or more 


than one ball could be dropping at the 
same time. Or the ball could zig-zag on 
its way down. And you might like to 
give it some sound effects. Try it-you’ll 
learn a lot by tinkering! 

And if you come up with anything 
interesting, send it in and let us have a 
look. 


&40 bytes ahead of the arrow’s top left 
screen location. If the screen byte returned is 
zero, indicating no collision, the branch is 
taken, otherwise, a collision has occured. 

680 Makes a beep - VDU 7 - indicating a 
collision. 

690 Erases the ball from the screen and starts the 
program again. 

700 Puts the arrow on the screen in its new 
position. 

710 Waits for next screen re-fresh - OSBYTE 
19. This gives smooth movement and 
reduces flicker. 

720 Deletes the ball from the screen. 

730 Decreases the ball’s Y coordinate to move it 
down the screen. The number subtracted 
depends on the contents of the location given 
by the variable speed. This will be either 2 or 
3 depending on the number stored there at 
the start of the main loop - see line 440. 

740 Checks if the new Y coordinate is greater or 
equal to 10. If this is true the branch is taken 
because the ball has not gone off the bottom 
of the screen. 


750 

760-770 

780-820 


830-870 


880-890 


900 

910 

920-970 

990-1010 
1030-1110 
1 120-1360 


Deletes the arrow from the screen then 
jumps back to the start of the program. 
Display the ball in its new position then jump 
to start of main loop. 

Display/erase the arrow on/from the screen. 
Before the sprite routine can be called 
various information must be set up. This 
includes the graphic data pointer - 790-800 
- the screen address - 810 - and the sprite’s 
dimensions-820. 

Display/erase the ball on/from the screen. 
See the previous description for additional 
information. 

Check if a certain key is pressed. On entry 
the X register should contain the negative 
inkey number of the key to be tested. On exit 
the Z flag will be 1 if the key is pressed and 0 
if it’s not. 

Generates a random nybble in the X register. 
Generates a random byte in the 
Accumulator. 

Reserve room for various variables used by 
the routine. 

Read the sprite graphic data into page &C. 
The arrow graphic data. 

The ball graphic data. 
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740 .replaceball JSRballonscreen 
770 JHPrepeatl 
780 .arroxonscreen 
790 LDAI8:STftcolu«n+l 
800 LDAI6C:STAcolu*n+2 
810 LDKarroHlt:LDYarronYiJSRcalc loc 
820 LDX*8:LDY48:JMPsprite 
830 .ballonscreen 
840 lDAI440:STAcolu«n+l 
850 LDA*6C:STAcolu«n+2 
860 LDXbal 1X:LDYbalIY:JSRcalc loc 
870 L0Xt8:LDY#24:JMPsprite 
880 .inkey LDA»6B1:LDY»6FF 
890 JSR«tFFF4:CPYiiFF:RTS 
900 .randnyb JSRrando«bytesANDI4F:T 
AX:RTS 

910 .randoibyte SEI:LDA&FE68:EOR&FE 
44:E0R4tFC: CLI: RTS 
920 .arroMX NOP 
930 .arroxY NOP 
940 .bal1X NOP 
950 .bal1Y NOP 
960 .loveflag NOP 
970 .speed NOP 
980 1NEXT 

990 FOR IX=0 TO IFF 
1000 READ LX7&C00 
1010 NEXT 
1020 END 

1030 REN Arrox data 


1040 DATA*tF,0,3,*t3F,*t3F,3,0,iF 
1050 DATA5,6A,3,63F,63F,3,4A,5 
1060 DATA6A,6A,3,43F,63F,3,4A,6A 
1070 DATA0,0,3,43F,63F,3,0,0 
1080 DATA0,0,3,&3F,&3F,3,0,0 
1090 DATA1,0,3,&3F,&3F,3,0,1 
1100 DATA62B,617,3,63F,63F,3,617,62B 
1110 DATA0,2,62B,63F,63F,62B,2,0 
1120 REN Ball data 

1130 DATA0,614,614,614,614,614,630,6 
30 

1140 DATA63C,430,630,630,630,630,430 
,630 

1150 DATA63C,630,414,614,614,611,633 
,633 

1160 DATA614,630,630,630,629,429,629 
,630 

1170 DATA63C,630,430,430,630,63C,630 
,430 

1180 DATA63C,630,633,633,636,636,633 
,433 

1190 DATA63C,63C,630,630,3,3,3,616 
1200 DATA43C,630,634,434,630,630,430 
,638 

1210 DATA63C, 630,636,636,630,630,630 
,414 

1220 DATA63C,630,430,630,630,430,630 
,430 

1230 DATA43C,630,630,630,630,630,630 
,630 


1240 DATA63C,630,430,430,630,630,630 
,630 

1250 DATA63C,630,630,630,630,430,630 
,430 

1260 DATA63C,630,630,630,630,630,630 
,630 

1270 DATA63C, 430,630,630,630,630,630 
,630 

1280 DATA63C,630,430,630,3,3,3,629 
1290 DATA63C,630,638,638,630,630,630 
,634 

1300 DATA63C,630,639,639,630,430,430 
,628 

1310 DATA628,630,630,630,616,616,618 
,430 

1320 DATA63C,630,630,430,630,630,630 
,430 

1330 DATA63C,630,633,633,639,639,633 
,633 

1340 DATA0,628,628,628,628,628,630,6 
30 

1350 DATA63C,630,630,430,630,630,630 
,630 

1360 DATA63C,630,428,428,628,622,633 
,633 


This listing is included in this 
month ’s cassette tape offer. See 
order form on Page 173. 


DISC DRIVES 

D80SMP Dual Drive (2x400K) 40/80 

switchable, double sided + Monitor 
Stand + PSU £320 inc VAT (b) 

S80SP Single Drive (400K) 40/80 switchable 

double sided + PSU £160 inc VAT (b) 
S80S Single Drive (400K) 40/80 switchable¬ 
doublesided £120 inc VAT (b) 

S80FD Single Drive (400K) Full height 80 track 
double sided £1OO inc VAT (b) 

S80F Single Drive (200K) 80 track 

single sided £80 inc VAT (b) 

S40S Single Drive (10OK) 40 track 

single sided £1 OO inc VAT (b) 

D35 Dual 3.5" drives (800K) 80 track 

double sided £200 inc VAT (b) 

S35 Single 3.5" drive (400K) 80 track 

double sided £115 inc VAT (b) 

All drives fully cased and cabled. 

Acorn Interface £55 inc VAT (c) 

Acorn DNFS £75 inc VAT (c) 

8271 £46 inc VAT (a) 27128 £5 inc VAT (a) 

2764 £2.75 inc VAT (a) 6264LP £5 inc VAT (a) 

Quantity discounts available 

CARRIAGE CHARGES 
(a) £1.00 (b) 10.00 (c)£2.00 


yw 84 High 


CARSON DEVELOPMENTS (MU) 
Highfield Road, Romford, Essex, RM5 3RU 
Telephone: 0708 27043 


DISKETTES from £10 per pack (ex VAT). 

All diskettes are guaranteed and have a lifetime warranty. 


40tk ss sd 
40tk ss dd 
40tk ds dd 


10 of 25 of 

11.50 27.00 
12.65 29.00 
15.00 35.00 


80tk ds quad 17.00 41.00 
Prices inc VAT + carriage. 

Datalife Verex 
40tk ss sd - 

40tk ss dd 13.50 

40tk ds dd 17.50 

80tk ds quad 23.00 


Add £7.00 for a 50 capacity 
storage box with smoked 
perspex lid. dividers and non-slip 
rubber feet. 

Sony 

3.5" ss dd £38.00 
3.5" ds dd £45.00 

Prices inc VAT. Please add 
£1.00 carriage. 


Are you frustrated by page problems, running 2 or more DFS's, ROM 
interaction, require a single and double density sector editor? 

The new SYSTEMS UTILITY ROM from EDSOFT is your answer. 
With SYSTEMS UTILITY you can: 

Sector edit Acorn, Opus and UDM. 

Enable/Disable ROMs - even across control break. 

List ROMs. 

Check status of ROMs even when disabled. 

PEEK and POKE memory. 

Display BASIC variables. 

Automatically run the BASIC/MC file from disc and leave PAGE at 
&EOO. 

Automatically download cassette software from disc. 

Display function keys. 

Plus numerous other features. £20 inc VAT (c) 


UDM DDFS3.0 
UDM 100% Board 

UDM ROM/16K RAM Expansion Board 
UDM 3.0 Upgrade 


£80 inc VAT (a) 
£17.50 inc VAT (a) 
£55 inc VAT (c) 
£5.75 inc VAT (a) 


* 


NEW REPLICA II 

Tape to Disc utility for Acorn, 

Opus 4- UDM PDFS 


£12 inc VAT (a) 


Slimline Drive Case £13.80 inc VAT (c) Full Height Drives 

Case £18.98 inc VAT (c) 

Single Drive Data Cable £6.50 inc VAT (a) Single Drive Power 

Cable £3.50 inc VAT (a) 

Dual Drive Power Cable £4.75 inc VAT (a) 


Dual Drive Data Cable £10.50 inc VAT (a) 
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